threading synchronization problem

  • Thread starter Thread starter Perecli Manole
  • Start date Start date
P

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
 
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.
 
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:
Click to expand...

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.
Click to expand...

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.
Click to expand...

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
 
Perecli Manole said:
I am not using WaitHandle but the AutoResetEvent class which is similar in
usage.
Click to expand...

That means you *are* using a WaitHandle - AutoResetEvent derives from
WaitHandle.
Yes I read the documentation.
Click to expand...

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.
 
Thank you for that great write up. That is what I was looking for and it
makes sense.

Perry
 
Back
Top