Mutex and binary semaphore
syuga
I haven't used Linux very much. I had been working on VxWorks and am
migrating to VxWorks.
I would like to know the differences between mutex and binary
semaphore. I have already done a google but at the end of it I was
frustrated and more confused. Kindly help.
In VxWorks, binary semaphore is used for both mutual exclusion and
synchronization. It depends on how it is initialized (SEM_FULL vs
EMPTY). For problems related to mutual exclusion, a mutual exclusion
semaphore is provided which can be used to handle priority inversion,
deletion safety etc.
I am trying to understand the diff between a mutex in Linux and a
binary semaphore in linux and VxWorks
Mutex - Linux bin semaphore
Mutex - VxWorks bin semaphore.
Appreciate your help.
Thanks,
syuga
Jens Thoms Toerring
> I haven't used Linux very much. I had been working on VxWorks and am
> migrating to VxWorks.
> I would like to know the differences between mutex and binary
> semaphore. I have already done a google but at the end of it I was
> frustrated and more confused. Kindly help.
> In VxWorks, binary semaphore is used for both mutual exclusion and
> synchronization. It depends on how it is initialized (SEM_FULL vs
> EMPTY). For problems related to mutual exclusion, a mutual exclusion
> semaphore is provided which can be used to handle priority inversion,
> deletion safety etc.
> I am trying to understand the diff between a mutex in Linux and a
> binary semaphore in linux and VxWorks
Since no one else has answered yet I will give it a try. But please
note that I don't know VxWorks and if there's something special I
don't know about. Amd perhaps I am misunderstanding yoru problem
completely...
To my understanding a mutex is nothing else then a binary semaphore,
i.e. a semaphore that can only count from 0 to 1. Normal semaphores
can be used to control a larger number of resources, so they can e.g.
be set at the start to the total value of available resource items
and each call of down() (or however you like to call that function)
decreases the semaphores count. Only if it's down to 0 the next call
of down() will block the caller until something else calls up() (or
perhaps you prefer the name post()) on the semaphore, making one
instance of the resource available for another caller of down().
A mutex works the same but it can only have a count of either 1 or
0, so it can be used only to manage a resource of which there is
only one available instance (like access to a certain memory area).
So, at least under Linux, a mutex is just a special case of a sema-
phore, a binary semaphore.
A function like e.g. pthread_mutex_lock() is just a call of down()
and pthread_mutex_unlock() of up() on a binary semaphore.
Now, some confusion can result from the different ways semaphores
and mutexes (is that the correct plural?) can be obtained. There
are the older SysV IPC semaphores, POSIX semaphores and mutextes
in threading. The first two are mostly used for interprocess com-
munication and synchronisation (i.e. between more or less unre-
lated processes) and are more general since they can count beyond
1 while mutexes are for synchronisation between different threads
of a single process. A thing one should keep in mind when using
semaphores in a threaded program is that each thread in the pro-
cess can do an up() on a SysV or POSIX semaphore since they "be-
long" to the process, not a single thread, while (as far as I
know) a thread mutex can only be unlocked by the thread that did
the locking. That's because the SysV and POSIX semaphores were
originally meant for IPC between different processes and not with
the special needs of threads in mind.
Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de
David Schwartz
> A function like e.g. pthread_mutex_lock() is just a call of down()
> and pthread_mutex_unlock() of up() on a binary semaphore.
One huge difference that must be kept in mind though -- the thread
that calls 'pthread_mutex_lock' *owns* the mutex. It is the only
thread that can call 'pthread_mutex_unlock' to release the mutex.
Semaphores do not have a concept of thread ownership.
A mutex is a very fast, light primitive. It provides only mutual
exclusion. That is, one and only one thread can own the mutex at a
time.
DS
syuga
I agree that the mutex would be optimized for speed.
Also, if I were to use a binary semaphore for mutual exclusion (in
VxWorks context),
only the task that takes the semaphore can release it, not necessarily
the task that created it.
What you are saying is that a mutex can only be taken and given by the
thread that created it, right ?
May be I am missing something, but please clarify this.
If I have 2 tasks A & B and thread A has created a mutex (ie. owner).
Now, lets say they want to access a shared resource, can't thread B
take the mutex and release it if it wants access to shared resource
first?
This is allowed in VxWorks, but not sure about Linux. Its really
getting more confusing for me...
syuga
David Schwartz
> What you are saying is that a mutex can only be taken and given by the
> thread that created it, right ?
No. A mutex can only be *released* by the thread that *acquired* it. A
semaphore can be up or down. But a mutex can be owned by a particular
thread or unowned.
> May be I am missing something, but please clarify this.
>
> If I have 2 tasks A & B and thread A has created a mutex (ie. owner).
Creating a mutex doesn't make you its owner.
> Now, lets say they want to access a shared resource, can't thread B
> take the mutex and release it if it wants access to shared resource
> first?
Sure. While thread B has the mutex, it owns it.
DS
Rainer Weikusat
> On Feb 12, 4:40 am, David Schwartz <dav...@webmaster.com> wrote:
>> On Feb 11, 12:35 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
>> > A function like e.g. pthread_mutex_lock() is just a call of down()
>> > and pthread_mutex_unlock() of up() on a binary semaphore.
>>
>> One huge difference that must be kept in mind though -- the thread
>> that calls 'pthread_mutex_lock' *owns* the mutex.
[...]
> What you are saying is that a mutex can only be taken and given by the
> thread that created it, right ?
No. The pthreads-specification demands that a locked mutex can only be
released by the thread which locked it. This thread is called the
(current) 'owner' of the mutex.
syuga
This applies to a binary semaphore too. Lets say there are 2 threads,
A & B.
Currently thread A has taken the semaphore and is in the critical
section. If thread B wants to enter the CS, it will have to wait till
thread A is done and gives up the semaphore. This is the same as a
mutex, so coming back to my original question, what's the diff.
between a mutex and a binary semaphore.It seems like both can be used
for mutual exclusion ?
Jens Thoms Toerring
It depends on the implementation of that mythical "binary sema-
phore". If this binary semaphore is part of the threading system
like the mutex you create with a variable if type pthread_mutex_t
then it's guaranteed that only the thread that locked the mutex
can unlock it. But if you use a semaphore implementation that is
completely unrelated to threads like a SysV or a POSIX semaphore
then all threads in the same process that locked the semaphore
can unlock it. Only another *process* can't unlock it.
So while "semaphore" and "mutex" are, on the one hand, abstract
constructs (and then a mutex isn't anything else than a binary
semaphore), you also have to consider the real implementation
of that abstract concept. And a semaphore implementation that
works on a process (and not thread) level will not keep one
thread of a process from unlocking a semaphore that has been
locked by a different thread in the same process. You have to
distinguish between "process semaphore" or "process mutex" and
"thrad semaphore" or "thread mutex". A "thread mutex" will be
rather useless if you want to synchronize to different processes
and a "process semaphore" will unsuitable for synchronizing the
threads within a process.