The example for Asynchronous I/O (and I/O Asynchronous Completion) is racy. Two locks are used to protect the same information, but their use is inconsistent. Try, for example, to add a Thread.Sleep(30000) in the main thread after unlocking NumImageMutex but before acquiring LockObject

bool mustBlock = false
lock (NumImagesMutex)

if (NumImagesToFinish > 0
mustBlock = true

if (mustBlock)

Console.Write("All worker threads are queued. ")
// sleep longer than the image processing take
Thread.Sleep(30000)
Console.WriteLine("Blocking until they complete. numLeft: {0}.", NumImagesToFinish)
lock(WaitObject

Monitor.Wait(WaitObject)



If I were to build a similar piece of code, I would use only one lock scoped around the currently used lock/unlock sequences

In the Callback

lock(WaitObject

if (--NumImagesToFinish == 0)

Monitor.Pulse(WaitObject)



And in the main thread

lock(WaitObject

if (NumImagesToFinish > 0

// Normally, you would avoid blocking operations under loc
Console.WriteLine("All worker threads are queued. Blocking until they complete. numLeft: {0}.", NumImagesToFinish)
Monitor.Wait(WaitObject)



Bye

[quoted text, click to view]

...

[quoted text, click to view]

________________


Thanks for the feedback, Marijn. I've opened a bug to track this. FYI, you can send feedback on the documentation directly to the appropriate writer: At the bottom of every topic, there's a
comment link that opens an e-mail with pre-formatted subject line.

Glenn Hackney
Microsoft
This posting is provided "as is" with no warranties and confers no rights.