threading synchronization problem

[Perecli Manole]

I have this kind of construct:

Somewhere in thread 1 -------------------------------------------------

SyncLock _objTxRxSync
'code to set some values in _objTxRxSync object


If _objSignal.WaitOne(1000, True) Then
'do stuff when other thread signals
Else
'do stuff when timeout
End If
End SyncLock

Somewhere in thread 2 -------------------------------------------------

SyncLock _objTxRxSync
'code to set some values in _objTxRxSync object

_objSignal.Set()
End SyncLock

--------------------------------------------------------------------------

The problem is that thread 1 never gives up the lock on _objTxRxSync during
the 1000ms wait for thread 2 to access. The documentation states that if the
second parameter for the WaitOne method is set to True, the waiting threat
should give up the lock of the sync context and reaquire it when signaled.
Why does this not work? I am using .NET v2.0 latest release. Is this a bug?


Thanks
Perry

 

[Nick Hertl]

I think that you may be confused about the meaning of the second
parameter.

I assume that you are using the System.Threading.WaitHandle class and
calling the WaitOne(int, bool) function on that type.
The meaning of that boolean is as follows:

exitContext
true to exit the synchronization domain for the context before the wait
(if in a synchronized context), and reacquire it afterward; otherwise,
false.

If the second thread does not give up the lock, there is nothing that
you can do to get it back. Not even something as agressive as a
ThreadAbort would necessarily solve the problem, unless of course you
had a finally block on your second thread that released this lock.

This is not a bug, but rather I think just a misunderstanding of how
the API should work.

 

[Perecli Manole]

I assume that you are using the System.Threading.WaitHandle class and

calling the WaitOne(int, bool) function on that type.
The meaning of that boolean is as follows:

I am not using WaitHandle but the AutoResetEvent class which is similar in
usage.

exitContext
true to exit the synchronization domain for the context before the wait
(if in a synchronized context), and reacquire it afterward; otherwise,
false.

Yes I read the documentation.

If the second thread does not give up the lock, there is nothing that
you can do to get it back.
Not even something as agressive as a
ThreadAbort would necessarily solve the problem, unless of course you
had a finally block on your second thread that released this lock.

I was not taking about the second thread giving up the lock. That works
fine. I was talking about the first thread giving up the lock during the
WaitOne(1000, true) method.

You missed my whole point. The second thread was shown in the example just
for reference.

Perry

 

[Jon Skeet [C# MVP]]

I am not using WaitHandle but the AutoResetEvent class which is similar in
usage.

That means you *are* using a WaitHandle - AutoResetEvent derives from
WaitHandle.

Yes I read the documentation.

But unfortunately without understanding it. That's not entirely
surprising, as the docs don't actually explain what a synchronisation
domain is.

At some stage I intend to update my threading article with information
about it (as some kind folks have sent me references) but for the
moment, I'd just recommend using Monitor instead of AutoResetEvent. You
just need to lock on the same thing that you Wait on, and that lock
will be released.

See http://www.pobox.com/~skeet/csharp/threads/deadlocks.shtml (second
half) for examples of using Monitor.Wait/Pulse.

 

[Perecli Manole]

Thank you for that great write up. That is what I was looking for and it
makes sense.

Perry