友情提示：如果本网页打开太慢或显示不完整，请尝试鼠标右键“刷新”本网页！
VB2008从入门到精通(PDF格式英文版)-第68部分
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！
For Each item In items
Console。WriteLine（〃Item （〃 & item & 〃）〃）
Thread。Sleep（&H3E8）
Next
End Sub
…………………………………………………………Page 377……………………………………………………………
C HA P TE R 1 3 ■ L E AR N IN G AB O U T M U L T IT HR E AD IN G 355
Sub Task2（）
Thread。Sleep（1500）
SyncLock elements
elements。Add（30）
End SyncLock
End Sub
Sub Main（）
elements。Add（10）
elements。Add（20）
Dim thread1 As New Thread（AddressOf Task1）
Dim thread2 As New Thread（AddressOf Task2）
thread1。Start（）
thread2。Start（）
End Sub
End Module
The code still uses a lock； but only in the places where it is necessary。 When the collection
is being iterated； the lock is applied to the operation of copying the collection to an array
（ToArray（））。 For the array iteration itself； there is no lock。 When writing to the collection； there
is a lock。
So； how can it be more efficient to take a snapshot of the collection； since taking a snap
shot takes time？ The answer is that normally it is not more efficient； but it is more time…slice
effective。
Consider a word processor that loads some text。 When Microsoft Word loads text； it imme
diately displays the first page； allowing you to edit right away。 In the background； you see the
other pages being loaded and prepared for editing。 Using the snapshot approach； you get the
same effect。
As a general threading rule； use locks as sparingly as possible； but use them whenever
necessary。 If you do use them； use them for as little code as possible。 Locks synchronize access
to resources； and thus only a single thread can be executing for a locked piece of code。 The less
time code is locked； the faster your code will be。
How Not to Deadlock Your Code （Mostly）
A deadlock makes code stop executing。 A deadlock occurs when one piece of code has a lock
and waits for some information to bee available。 However； the information does not
bee available； because another thread that could provide that information is waiting for a
lock to bee free。
I’ve said that if you are using locked code； you should use it as sparingly as possible。 That’s
because using locks can lead to deadlocks。 Deadlocks are a royal pain in the butt。
Consider the following two…thread collection example。
。 。 。
Module ThreadProblem
Dim elements As List（Of Integer） = New List（Of Integer）（）
…………………………………………………………Page 378……………………………………………………………
356 CH AP T E R 1 3 ■ L E A R N I N G A B OU T M U L T I TH R E A DI N G
Sub Task1（）
Dim items As Integer（）
Thread。Sleep（1000）
SyncLock elements
Do While （elements。Count 《 3）
Thread。Sleep（1000）
Loop
items = elements。ToArray（）
End SyncLock
Dim item As Integer
For Each item In items
Console。WriteLine（〃Item （〃 & item & 〃）〃）
Thread。Sleep（1000）
Next
End Sub
Sub Task2（）
Thread。Sleep（1500）
SyncLock elements
elements。Add（30）
End SyncLock
End Sub
Sub Main（）
elements。Add（10）
elements。Add（20）
Dim thread1 As New Thread（AddressOf Task1）
Dim thread2 As New Thread（AddressOf Task2）
thread1。Start（）
thread2。Start（）
End Sub
End Module
The iteration code waits until the collection count is 3。 However； this never happens； because
the thread that could make the collection count 3 is waiting for the lock to bee free。 The
bolded code is the waiting code that queries whether the collection count is 3。 If it is not； the
thread waits for 1 second and asks again。 But throughout all of this waiting； the lock is never given
up； and thus the second thread that could add an element is waiting。 The code will deadlock。
Without modifying the locks； here is a tweak that will avoid the deadlock （the thread sleeps for
only 0。5 seconds instead of 1。5 seconds； so the writing thread can get in first before the reader
thread gets in）：
Sub Task2（）
Thread。Sleep（500）
SyncLock elements
elements。Add（30）
End SyncLock
End Sub
…………………………………………………………Page 379……………………………………………………………
C HA P TE R 1 3 ■ L E AR N IN G AB O U T M U L T IT HR E AD IN G 357
The single change （shown in bold） makes the code work。 In the first version； the timing
of the code was such that the reading thread went first。 In this version； the writing thread goes
first。 This shows that deadlocks are often timing…related。
The annoying part of deadlocks is that your code’s behavior is not deterministic。 Determin
istic behavior is when an action will result in a single result； as in the case with most source
code。 Typically； when you have a bug； you didn’t think far enough ahead and can work through
the error systematically。 However； with threading； your code ceases to be deterministic； because
timing can change the behavior。 Timing can be an influence in many ways： resource swapping；
debuggers； microprocessor speed； and a host of other features。
To make the code deterministic； you need to fix the part of the code that hung onto the lock
when it should not have。 Remember the cardinal rule： keep a lock for as short a time as possible。
You need to use a more advanced lock construct that allows you to wait for data to bee
available。 has quite a few constructs related to threading and synchronization； and each
construct is specific to the type of problem you are trying to solve。 In the case of a deadlock； you
want to use the Monitor type。 The Monitor type is an advanced synchronization type that allows
locking and pulsing of trigger signals for those threads that are waiting。
Let’s return to our multiple cooks in the kitchen analogy。 Say one cook needs a particular
fish pan； which is already being used by another cook。 Does the waiting cook tap her foot beside
the cook doing the cooking？ Or does the waiting cook do something else and ask the cook using
the pan to inform her when the pan is free？ Most likely； the cook will do something else and
wait to be informed that the pan is free。
This concept of working together and being able to notify other lock users is a powerful
feature programmed into the Monitor type。 Monitor has the ability to take a lock； give it up so
others can get the lock； and then take it back again。
When using the Monitor type； you do not declare a block of code that is protected； because
Monitor is much more flexible than that。 For example； you could define a class that has an
instance…level lock mechanism； like this：
Class DoSomething
Public Sub GetLock（）
Monitor。Enter（Me）
End Sub
Public Sub ReleaseLock（）
Monitor。Exit（Me）
End Sub
End Class
Any code that uses a Monitor is not restricted to where it’s placed in the code； but a Monitor
is bound to a thread。 So if a thread grabs a Monitor （by calling the Enter（） method on the
Monitor object）； it has control until the thread dies or the thread gives up control （by calling the
Exit（） method on the Monitor object）。 This has the added benefit that； once having acquired a
lock； a Monitor can get it over and over again。 However； if the same thread locked the Monitor
five times； the same thread needs to release it five times before another thread can be granted
access to the lock。
The following is the rewritten two…thread source code that uses a Monitor。
…………………………………………………………Page 380……………………………………………………………
358 CH AP T E R 1 3 ■ L E A R N I N G A B OU T M U L T I TH R E A DI N G
Sub Task1（）
Dim items As Integer（）
Thread。Sleep（1000）
Monitor。Enter（elements）
Do While （elements。Count 《 3）
Monitor。Wait（elements； 1000）
Loop
items = elements。ToArray（）
Monitor。Exit（elements）
Dim item As Integer
For Each item In items
Console。WriteLine（〃Item （〃 & item & 〃）〃）
Thread。Sleep（1000）
Next
End Sub
Sub Task2（）
Monitor。Enter（elements）
elements。Add（30）
Monitor。Pulse（elements）
Monitor。Exit（elements）
End Sub
The bolded code lines are the new pieces that use the Monitor type。 In the definition of the
first thread to get the lock； the Monitor。Enter（） method is called with the parameter elements；
which； as in the earlier SyncLock example； defines the lock reference handle。 Once the lock has
been acquired； the thread checks to see if the list count is greater or equal to 3。 If the counter is
less than 3； the Monitor。Wait（） method is called。 The behavior of Monitor。Wait（） is similar to
Thread。Sleep（）； except that the Monitor lock is given up。
Releasing the lock is a unique feature of a Monitor。 The lock is given up only during the
time that the caller is in Monitor。Wait（）。 When the Monitor。Wait（） method returns； the lock is
acquired again。 The code says that the thread is reawakened after 1 second。 After that second；
the thread does not have the lock and needs to wait before it can acquire the lock。 If another
thread is holding onto the lock for a long time； it could take a while to get the lock back again。
Another way for the Monitor。Wait（） method to awaken is if a signal is sent by another
thread。 The code for the second thread uses Enter（） and Exit（）； but also Pulse（）。 The Monitor。
Pulse（） method triggers a signal that awakens the first thread； but the first thread will execute
only after the second thread has released control of the lock。
The big advantages of a Monitor in parison to SyncLock are that the Monitor can be
used anywhere in the code and that the Monitor will release a lock while waiting for an answer。
You would use SyncLock when you want to control access to a block of code。 If the access goes
beyond method boundaries； then it is preferable to use Monitor。 It is not that you could not use
a SyncLock that spanned boundaries； but if you need to add code that could produce a dead
lock； it is easier to control that code using a Monitor。
Now that we’ve covered the fundamentals of multithreading； the next sections focus on
more advanced threading architectures—reader/writer and producer/consumer—and using
asynchronous calls。
…………………………………………………………Page 381……………………………………………………………
C HA P TE R 1 3 ■ L E AR N IN G AB O U T M U L T IT HR E AD IN G 359
Implementing a Reader/Writer
Threaded Architecture
The reader/writer threaded architecture is based on the idea that if one thread is reading and
another thread would like to read as well； why not let it？ However； if one thread wants to write；
then only that thread can write。 In other words； multiple threads are allowed to read data
simultaneously； but to write； a thread must have an exclusive lock。
implements a System。Threading。ReaderWriterLock class； which contains the reader/
writer functionality。 This class is like a Monitor； in that it gives you the control to manage how
data is accessed but does not determine what you are accessing。 The ReaderWriterLock type
has a number of methods and properties。 The most important ones are listed in Table 13…1。
Table 13…1。 Important ReaderWriterLock Methods
Method Description
AcquireReaderLock（） Acquires a reader lock。 Multiple threads can acquire a
reader lock。
AcquireWriterLock（） Acquires a writer lock。 Only a single thread can acquire
a writer lock。
DowngradeFromWriterLock（） Converts a writer lock into a reader lock。 Using this
method avoids the need to call ReleaseWriterLock（）
and AcquireReaderLock（）。
UpgradeToWriterLock（） Converts a reader lock into a writer lock。 Using this
method avoids the need to call ReleaseReaderLock（）
and AcquireWriterLock（）。
ReleaseLock（） Releases all locks； regardless how many times you have
called to acquire the reader or writer locks。
ReleaseReaderLock（） Decrements the reader lock a single count。 To pletely
release a reader lock； you need to make sure the number
of times you called ReleaseReaderLock（） is equal to the
number of times you called AcquireReaderLock（）。
ReleaseWriterLock（） Decrements the writer lock a single count。 To pletely
release a reader lock； you need to make sure the number
of times you called ReleaseWriterLock（） is equal to the
number of times you called AcquireWriterLock（）。
Let’s look at a collection example that has four threads： three read
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部!
温馨提示： 温看小说的同时发表评论，说出自己的看法和其它小伙伴们分享也不错哦！发表书评还可以获得积分和经验奖励，认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦！