Thread Synchronization

[Maqsood Ahmed]

Hello,

I asked a question regarding thread synchronization on this usergroup
some days back. I was using the AutoResetEvent class for signalling
between two threads. The problem with AutoResetEvent was that it
sometimes it used to stop working a thread never come back from Wait
state.
I implemented Monitor for signalling following the suggestions came in
reply to that post. It started to getting worse and the application
started to hang (become irresponsive). I googled around and found that
there occurs a deadlock when Invoke is called on a control within the
Monitor lock. The alternatives were

i. Call the method (which is invoking the control) outside the lock
ii. Use BeginInvoke instead of Invoke.

both solutions were not feasible with current implementation of the
software, so we decided to device a custom signalling mechanism using
the Socket connections with the loopback address and writing and
reading a byte to Set and Wait respectively. This became even worse
and sometimes application as well as OS is hanged.

PC is Intel P4 2.67 with 2GB RAM. The user usually uses 9 to 10
instances of MS Excel, MS Outlook, Internet Explorer (several
instances) and some other applications.

Can anyone of you suggest what might be the cause of the problem? It
is a simple Producer/Consumer pattern, is it related to the PC
resource (GDI objects etc).

Regards

Maqsood Ahmed
Kolachi Advanced Technologies
http://www.kolachi.net

 

[Jon Skeet [C# MVP]]

I implemented Monitor for signalling following the suggestions came in
reply to that post. It started to getting worse and the application
started to hang (become irresponsive). I googled around and found that
there occurs a deadlock when Invoke is called on a control within the
Monitor lock.

Only if you try to acquire the same lock from the UI thread.

The alternatives were

i. Call the method (which is invoking the control) outside the lock
ii. Use BeginInvoke instead of Invoke.

both solutions were not feasible with current implementation of the
software, so we decided to device a custom signalling mechanism using
the Socket connections with the loopback address and writing and
reading a byte to Set and Wait respectively. This became even worse
and sometimes application as well as OS is hanged.

You've got a fundamental problem if the alternatives listed above
aren't feasible for you. You need to redesign so that they *are*
feasible, rather than rolling your own locking strategy which will
have the same problems.

PC is Intel P4 2.67 with 2GB RAM. The user usually uses 9 to 10
instances of MS Excel, MS Outlook, Internet Explorer (several
instances) and some other applications.

Can anyone of you suggest what might be the cause of the problem? It
is a simple Producer/Consumer pattern, is it related to the PC
resource (GDI objects etc).

Well, you haven't really said what you're doing, but it *sounds* like
you're acquiring a lock in one thread, then trying to reaquire it in
the UI thread. That will deadlock because the UI thread won't be able
to acquire the lock until the worker thread has released it, and by
using Invoke instead of BeginInvoke the worker thread won't release
the lock until the UI has returned. Deadlock.

Now, if you could explain more about what you're trying to do, we may
be able to help you design your way out of that situation.

Jon

 

[Peter Duniho]

[...]
both solutions were not feasible with current implementation of the
software, so we decided to device a custom signalling mechanism using
the Socket connections with the loopback address and writing and
reading a byte to Set and Wait respectively. This became even worse
and sometimes application as well as OS is hanged.

In addition to what Jon wrote, I would suggest that you consider the
fact that deadlock is generally a consequence of design, not implementation.

In other words, it really doesn't matter how you communicate between
threads. If your code has deadlock potential, all you change by using a
different inter-thread signaling mechanism is how you wind up deadlocking.

Deadlock happens when one thread is waiting on another at the same time
that other thread is waiting on the first. You can change the way
threads wait on each other, but they will still deadlock.

Pete