I know i am asking a question which can be googled and find lot of explanation.
I have actually gone through many but none explained the ownership property completely.

Mutex is acquired by some process, only that process can unlock it

how the other process/thread know that the mutex is not created him.

where as a binary semaphore can be unlocked by any other process.

if Read task/process locks a semaphore for reading
and same time write task also needs can it unlock it
i am little confused here by the statement "can be unlocked by any other process."

Thanks in Advance,

4 Years
Discussion Span
Last Post by mike_2000_17

Since the context of your second statement is unknown, and, as it stands, is false, I think you are confusing two different problems thinking they are the same.


Basically, the difference between a mutex and a binary semaphore is that the semaphore is a more general mechanism which makes it somewhat less appropriate to do the same job as a mutex (although I guess it might be faster on some implementations).

Because you can have semaphores that carry any integer count (not just 0 or 1), it is intended for managing a resource pool with limited capacity. The general scenario is that multiple threads can increase (lock) the semaphore when they need to, and decrease (unlock) it when they are done, and if the semaphore reached its max-count when a thread attempts to lock it, that thread will have to wait. To keep things simple, the OS doesn't keep track of which threads currently have a lock on the semaphore and which don't, because if it did, it would be just like having a number of mutexes instead of one semaphore count. It's just a simpler (but sufficient and efficient) mechanism under-the-hood.

The (unfortunate) consequence of this simplicity is that the OS cannot guarantee that if a thread unlocks a semaphore, that that thread actually had locked it before, and vice versa. It is up to the programmer not to make such a mistake.

So, if you use a binary semaphore, you basically get a mutex, without the guarantee that only the thread that locked the mutex will be the one unlocking it. But, generally, if you code things correctly, it isn't hard to make sure that you do the locking and unlocking in an orderly fashion. But, for the most part, if you need a mutex, just use a mutex.

There are also uses for this property of semaphores, like forcing the un-locking. But these are more advanced topics and are beyond my competence in the matter. These kinds of tricks are very tricky and subtle, and usually require formal methods to analyse them carefully. It is the kind of voodoo you'd find in OS kernel code.

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.