A small change to the code for the mutex using semaphores:
void f() {
// Locking code
sem_wait(&sem1);
mutex_owner = getpid();
// CS
// Unlocking code
if(getpid() == mutex_owner) {
sem_post(&sem1);
} else {
abort(); // Invalid program operation: mutex not owned
@Monsieur: You're wrong. A mutex would be useless if it couldn't maintain a
queue of waiting processes. A binary semaphore is equivalent to a mutex only
under very restricted use cases. See the mail below for details.
@Dumanshu: No. In fact I mean to say the exact opposite. A binary semaphore
i
Hey guys,
A semaphore is an extension of a mutex. A mutex allows one thread
inside the critical section, a semaphore allows n threads in a
critical section (when the number n is given as a parameter on the
initialization). A semaphore is useful when a resource has more than
one instance, and a mute
@DK: So u mean to say that Mutex and binary semaphores provide
completely same functionality. Right?
Say u have a resource R and u can provide access to this particular
only one at a time (lets say multiple threads are there).
Now we can use mutex. One by one the threads will lock it and will use
t
@DK: absolutely..actually mutex is a kinda semaphore...and unlike
semaphores it does not have any list(of waiting processes) associated
with it and just is a kind of lock and key model with no waiting
Q.someone can say that they are Binary semaphore since binary
semaphore have only two values 0
@Dumanshu/@Ankit: Of course mutexes can be made to work between processes
(it's an implementation detail). But the *concept* of a mutex is Owner +
(Lock & Key) pair. By adding the concept of Owner to a lock, we can ensure
that only the person who locked the lock can open it. This *guarantees*
m
@Ankit: it seems like mutexes can work between processes. refer to
http://geeksforgeeks.org/?p=9102 m i right?
On Jun 17, 5:56 pm, ankit sambyal wrote:
> Yes, even the threads of a single process cannot have access to each
> others mutex.
> Mutexes can be applied only to threads in a single pro
