Re: help w/ mutex

From: Alexander Grigoriev (alegr_at_earthlink.net)
Date: 05/06/04 

Date: Wed, 5 May 2004 20:23:15 -0700

Mutexes are not any faster than semaphores, as they both involve switch to
kernel mode. The actual decision-making code is very simple for both.

Critical section is MUCH faster, if there is no contention for it. They also
allow recursion, like mutexes.

"andrea catto'" <acatto@dataflight.com> wrote in message
news:uGWWVBsMEHA.2976@TK2MSFTNGP10.phx.gbl...
> 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

  • [PATCH] kernel/cpuset.c mutex conversion comment fix
    ... The conversion of kernel/cpuset from semaphores to mutexes ... I didn't know offhand the state of read-write mutexes, ... - * We have two global cpuset semaphores below. ... - * zero, then only attach_task, which holds both semaphores, can ...
    (Linux-Kernel)
  • Re: [PATCH] use spinlock instead of binary mutex in idt77252 driver
    ... defined (I don't know what current kernels do), ... You need to verify the headerfiles for the above. ... Does this work with mutexes? ... New code should not use semaphores, ...
    (Linux-Kernel)
  • Re: help w/ mutex
    ... > Microsoft claims Mutexes are quicker, ... > Semaphores are non binary, they are based on a count-down, you can ... A semaphore can block a high priority thread ... the high priority thread to that of the lower priority thread. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: [patch 04/15] Generic Mutex Subsystem, add-atomic-call-func-x86_64.patch
    ... don't forget to compare this with our existing semaphore ... this means that mutexes will be _FAR MORE EXPENSIVE_ on ARM ... We'd be far better off sticking to semaphores ...
    (Linux-Kernel)