Re: help w/ mutex

From: andrea catto' (acatto_at_dataflight.com)
Date: 05/05/04 

Date: Wed, 5 May 2004 09:45:11 -0700

Here is what I empiricaly found,

Mutexes vs. Semaphores.
Microsoft claims Mutexes are quicker, who knows how much though.
Mutexes are thread-dependant, as already stated, if you try to 'get the
ownership' of a mutex with in the same thread, even from a different
function.
that same call will return positively as if you indeed just got it when in
reality you already got it at the first call.
Mutexes are 'binary' therefore the idea is, either you get the ownership or
you dont, and may possibly wait until the current owner will release it to
you.

Semaphores are non binary (only), they are based on a count-down, you can
use them in most cases to do the same things you could do with a mutex but
you have to define more parameters so it's easier in most cases to use
Mutexes.
On top of it all the MAJOR difference is semaphores are not
thread-dependant, they are merely count down dependant.
if you create a semaphore with 'count down' 3 until it gets to 0 it won't
trigger, and if you 'accidentally' call the waitforsingleobject twice on the
same semaphore within the same thread you are screwed.

I personally use 99% mutexes, as they are suggested by microsoft for speed
reasons, and they are simple and do most of the work.
I did use a semaphore once in a server application I made because for
example, I had to allow only 'so many' operations at the same time, so in
that particular case I created a semaphore with a given count, for instance
10, and only 10 instances of those operations could run, if 10 was reached
the next operation was waiting.

tell me if this clarifies.

"lallous" <lallous@lgwm.org> wrote in message
news:ufCFvTnMEHA.1032@tk2msftngp13.phx.gbl...
> hello Tom
>
> Yes, the fact that the same thread can acquire the mutex many times w/o
> blocking is the fact that I didn't know about although it was mentioned in
> the docs.
>
> Regards,
> Elias
> "Tom Stewart" <tastewar@newsgroups.nospam> wrote in message
> news:uXNSharLEHA.160@TK2MSFTNGP12.phx.gbl...
> > Not sure I follow your code exactly, but a single thread can acquire a
> mutex *recursively* What they are designed to
> > protect against is multiple threads (possibly from multiple processes)
> accessing some resource at the same time. If an
> > individual thread acquires a mutex recursively, it must release it the
> same number of times that it successfully
> > acquired it.
> >
> > If your application is single threaded, you can use global variables to
> track whether you "own" something or not. If
> > your application is multi-threaded, but you don't need cross-process
> protection, a CriticalSection is probably what you
> > need. If you have to deal with multiple processes, then a mutex is your
> friend. Or if you know the protected resource
> > will always be contended for, then the CriticalSection doesn't really
> offer any advantage.
> >
> > --
> > Tom
> >
> > "lallous" <lallous@lgwm.org> wrote in message
> news:%236ETzArLEHA.624@TK2MSFTNGP11.phx.gbl...
> > > Hello
> > >
> <snip code>
> > > Why the code in "method1()" doesn't block after the mutex has been
> acquired
> > > the first time?
> > > Should'nt the call to p1.acquire() lock if it was acquired first?
> > >
> > > I thought that a mutex would be acquired if you call
Waitforsingleobject
> and
> > > will be released with ReleaseMutex ...
> > >
> > > Please clarify.
> > >
> > > --
> > > Elias
>
>

Relevant Pages
Loading