Re: .net 2.0 : looking for a "best practice" for multi threading jobs

Steve B. <steve_beauge@xxxxxxxxxxxx> wrote:
I'm getting troubles in implementing the producer/consumer pattern for
multiple parralel threads...

Here where I am (a project class)... the code is simplified for better
read...

In some conditions, all threads are "blocked" in the GetNectAction() method
waiting in the Monitor.WaitOne method...

Do you have any idea what is wrong ?

Well, a few points:

1) You don't usually need one lock per variable. I tend to have one
lock for a whole instance of a class unless I have good reason to have
more granularity.

2) Point 1 opens you up for bugs where you lock on the wrong thing: for
example, SetStopped locks on m_numberOfThreadsLockObject to set
m_stopped, but the Stopped property locks on m_stoppingLockObject to
fetch it.

3) In Stop, you pulse all the waiting threads before setting the
stopping flag. Any thread which is still working when the pulse occurs
but requests a next action before m_stopping is set to true will wait
forever.

That's just what I could spot in a very quick scan. It would be much
better if I could run the code.

Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: the wait() and pulse() of monitor
    ... >> thread waiting for jobs, and another thread which produces jobs to be ... > but the pulse() just mean that the producer is ready to free the control ... > then the worker can get the lock. ...
    (microsoft.public.dotnet.framework)
  • Re: Monitor.Wait problem
    ... No one can know for sure that another Thread will call Pulse after I call ... All examples i saw on the net are just wrong, and they may block forever run ... At the time Thread1 calls Monitor.Wait, ... Why does Monitor.Wait not acquire the lock back if no other ...
    (microsoft.public.dotnet.framework)
  • Re: thread communication
    ... A more typical use of the Monitor class would be to have one thread using Waitand the other using Pulse(). ... lock ... -- Waitwill _release_ the lock and suspend the thread until some other thread calls Pulse; the suspended thread is moved into a wait queue for the lock ... The Monitor class isn't _always_ the right approach, but it does fit into the producer/consumer scenario very well, and is very useful in other patterns too. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: the wait() and pulse() of monitor
    ... >> Regain lock ... the producer would just pulse multiple times. ... > Sends a signal to one or more waiting threads. ...
    (microsoft.public.dotnet.framework)
  • Re: .NET Multithreading question
    ... "The thread that currently owns the lock on the specified object invokes ... the pulse, the waiting thread is moved to the ready queue. ...
    (microsoft.public.dotnet.languages.vc)