WaitHandle.WaitAll

[Eric Twietmeyer]

Hello,

I do not understand the docs for WaitAll. Firstly, what is a
"synchronization domain"? The third parameter to WaitAll is an
"exitContext", which is supposed to indicate whether or not to exit the
synchronization domain before the wait, and then reacquire it after the wait
completes. The only thing I can think of is if you have the following:

lock( some_object )
{
...
bool result = WaitHandle.WaitAll( wait_hdls, timeout, true );
...
}

then with third parameter "true" the lock on "some_object" would be released
before the wait starts, and then it would reacqurie it afterwards. In other
words, this is a synonym for:

lock( some_object )
{
....
}
bool result = WaitHandle.WaitAll( wait_hdls, timeout, false );
lock( some_object )
{
...
}

Is this correct? Is this what the last parameter is for?

Also the docs for WaitAll indicate that the returned bool is:

"true if the method exited the synchronization domain before the wait;
otherwise, false."

Is this correct?

Shouldn't the result indicate whether the wait was satisfied? Otherwise how
do you know whether the wait was satisfied or whether there was a timeout?
The documented return status makes no sense.

Thanks in advance,

Eric

 

[Guest]

Don't you hate that?! They mention Synchronization Domain and fail to
explain what it is.

If you use the SynchronizationAttribute on a ContextBoundObject, then access
to that object is automatically synchronized by the runtime. This is an
easier programming model for thread synchronization, but at the cost of fine
grain control.

However, when that object references another object, access to that object
is synchronized as well via the same lock as the original (depending on its
own SynchronizationAttribute). You can consider this object tree as the
synchronization domain. All the objects in a synchronization domain share
the same lock.

For more info
http://msdn.microsoft.com/library/d...cpguide/html/cpconmanagedthreadingsupport.asp
By using attributes, you get more coarse grain control over locking (as
opposed to using a Monitor), but you gain simplified development.

So if you exit context, that means you want to stop holding the lock on the
objects in the synchronization domain before you start waiting and try
reacquiring them after. If you set this to false, then you're holding a lock
while waiting for the notification, which could potentially open you up to
more deadlocking, though it may be the right choice for data integrity.

In any case, if you're not using synchronization domains, it probably
doesn't matter which one you choose.

http://haacked.com/