Hi,
Can anyone clear me that, when should we use go for mutex, and in which situation should we opt for monitor, lock, semaphone and other objects, in a multithreaded application for synchronization ?

Thanks

<"=?Utf-8?B?VmluYXkgQw==?=" <Vinay (E-Mail Removed)>>
wrote:
> Can anyone clear me that, when should we use go for mutex, and in
> which situation should we opt for monitor, lock, semaphone and other
> objects, in a multithreaded application for synchronization ?

I would suggest using Monitor (via the lock statement for Enter/Exit)
almost always. Mutex is useful if you want an inter-process lock.
Semaphores are useful for "counted" resources. Auto/ManulResetEvent are
useful for signalling situations where either you want to signal before
waiting (where Monitor.Pulse/Wait don't work as well) or you want to be
able to wait for any or all of multiple events.

See http://www.pobox.com/~skeet/csharp/multithreading.html for more
threading information. I'm updating it and adding
Auto/ManualResetEvent, but I haven't put that in yet.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

In a nutshell:
- Monitor.Enter/Exit and Mutexes are commonly used for protecting objects
from being used by two threads at the same time. Every thread acquires the
mutex (resp. enters the monitor) before it uses the object, and no other
thread will be allowed to do the same until the mutex is released (resp. the
monitor is exited); The Monitor methods are faster and use less memory,
mutexes can be shared across processes
- the lock statement internally uses the Monitor.Enter/Exit methods
- Monitor.Pulse/Wait are used for sending events to other threads;
Monitor.Wait will wait until "Pulse" is called by another thread. They are
usually used to wake up some idling thread. (AutoResetEvent/ManualResetEvent
serve similar purposes)
- Semaphores are much like mutexes, however they permit more than one access
at a time (e.g. it you want at most 3 of your threads accessing a database
at a time)

I hope this short intro helps a little; Jon Skeet has an excellent article
on multithreading, you could use google to find it.

Niki

"Vinay C" <Vinay (E-Mail Removed)> wrote in
news:3C79ACD0-04B7-4CD1-B36E-(E-Mail Removed)...
> Hi,
> Can anyone clear me that, when should we use go for mutex, and in which
situation should we opt for monitor, lock, semaphone and other objects, in a
multithreaded application for synchronization ?
>
> Thanks

Thank you, your matter was very useful. but still I have some queries
1. When I should chose monitor and when should I go for mutex, whats difference between them regarding performance.)
2. Please see a part of the code below:
public static void Main()
{
Threadpool1 tpool = new Threadpool1();
int total=2;
int completed =0;

ThreadPool.QueueUserWorkItem(new WaitCallback(tpool.increment));
ThreadPool.QueueUserWorkItem(new WaitCallback(tpool.decrement));

Thread.Sleep(500);

}
here I have to give Sleep() in main explicitly so that the main should not terminate before the threads in threadpool. Can you suggest the use of some other thing or callbacks so that we can know when the threads in threadpool are terminated thus avoiding Sleep() in main .

Eagerly waiting for the kind replies. :-)



"Jon Skeet [C# MVP]" wrote:

> <"=?Utf-8?B?VmluYXkgQw==?=" <Vinay (E-Mail Removed)>>
> wrote:
> > Can anyone clear me that, when should we use go for mutex, and in
> > which situation should we opt for monitor, lock, semaphone and other
> > objects, in a multithreaded application for synchronization ?
>
> I would suggest using Monitor (via the lock statement for Enter/Exit)
> almost always. Mutex is useful if you want an inter-process lock.
> Semaphores are useful for "counted" resources. Auto/ManulResetEvent are
> useful for signalling situations where either you want to signal before
> waiting (where Monitor.Pulse/Wait don't work as well) or you want to be
> able to wait for any or all of multiple events.
>
> See http://www.pobox.com/~skeet/csharp/multithreading.html for more
> threading information. I'm updating it and adding
> Auto/ManualResetEvent, but I haven't put that in yet.
>
> --
> Jon Skeet - <(E-Mail Removed)>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too
>

<"=?Utf-8?B?VmluYXkgQw==?=" <Vinay (E-Mail Removed)>>
wrote:
> Thank you, your matter was very useful. but still I have some queries
> 1. When I should chose monitor and when should I go for mutex, whats
> difference between them regarding performance.)

As I said before, only use Mutex for interprocess locking - it's much
less efficient than monitors.

> 2. Please see a part of the code below:
> public static void Main()
> {
> Threadpool1 tpool = new Threadpool1();
> int total=2;
> int completed =0;
>
> ThreadPool.QueueUserWorkItem(new WaitCallback(tpool.increment));
> ThreadPool.QueueUserWorkItem(new WaitCallback(tpool.decrement));
>
> Thread.Sleep(500);
>
> }

> here I have to give Sleep() in main explicitly so that the main
> should not terminate before the threads in threadpool. Can you
> suggest the use of some other thing or callbacks so that we can know
> when the threads in threadpool are terminated thus avoiding Sleep()
> in main .

You should make your work items effectively release a semaphore, and
try to acquire the semaphore the same number of times in your Main
thread. Alternatively, give each of them an event or monitor to
set/pulse and wait until both have been set/pulsed.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too