The Truth:while mutexes and semphores have similarites in their implementation, they should always be used differently.
The most common (but nonetheless incorrect ) answer to the above question is that mutexes and semphore are very similar, with only the significant difference being that semaphores can count higher than one.
When asked to expand on how to use a "counting semaphore" these are used to protect several equivalent resources. A counting semaphore is a synchronization object that can have an arbitrarily large number of states. The internal state is defined by a signed integer variable, the counter.
- Negative there are exactly -N threads queued on the semaphore.
- Zero no waiting threads, a wait operation would put in queue the invoking thread.
- Positive no waiting threads, a wait operation would not put in queue the invoking thread.
Two operations are defined for counting semaphores:
- wait This operation decreases the semaphore counter, if the result is negative then the invoking thread is queued.
- Signal This operation increases the semaphore counter, if the result is non-negative then a waiting thread is removed from the queue and resumed.
counting semaphores have no ownership attribute and can be signaled by any thread or interrupt handler regardless of who performed the last wait operation.
Because there is no concept a counting semaphore object can be created with any initial counter value
as long it is non-negative.Because there is no concept a counting semaphore object can be created with any initial counter value
The counting semaphore are usually as guards of resources avaliable in a discreate quantity. For example the counter may represent the number of used slots into a circular queue, producer would "signal" the semaphores when inserting items in the queue, consumer threads would "wait" for an item to appear in queue, this would ensure that no consumer would be able to fetch an item from the queue if there are no items avaliable.
A binary semaphore is a synchronization object that can only two states:
- Not taken
- Taken
- Take Taking a binary semaphore brings it in the "taken" state, trying to take a semaphore that is already taken enters the invoking thread into a waiting queue.
- Release Releasing a binary semaphore brings it in the "not taken " state if there are not queued threads. If there are queued threads then a thread is removed from the queue and resumed, the binary semaphore remains in the "taken" state. Releasing a semaphore that is already in its "not taken" state has no effect.
Binary semaphore have no ownership attribute and can be signaled by any thread or interrupt handler regardless of who performed the last taken operation. Because of this binary semaphore are often used to synchronize threads with external events implemented as ISR's .
Ex:waiting for a packet from a network or waiting that a button is pressed.
If a semaphore were a generalization of a mutex able to protect two or more identical shared resources, then in our analogy. The correct use of semaphore is for signaling from one task to another. By contrast, tasks that use semaphores either signal or wait--not both.
mutexwait(mutex_room)
// safely use shared resource
mutexRelease(mutex_room)
/* task1 producer */
sempost(sem_power_btn);
/*task2 consumer */
sempend(sem_power_btn);
Note: Importantly, semphores can also be used to signal from an interrupt service routine to a task. Signaling a semaphore is a non-blocking RTOS behavior and thus ISR safe. Because this technique eliminates the error-prone need to disable interrupts at the task level, signaling from within an ISR is an excellent embedded software more reliable by design.
Mutex:
A mutex is a synchronization object that can have only two states.
- Not owned
- Owned
Two operations are defined for muteses:
- Lock This operation attempts to take ownership of a mutex, if the mutex is already owned by another thread then the invoking thread is queued.
- Unlock This operation relinquishes ownership of a mutex. If there are queued therads then a thread is removed from the queue and resumed, ownership is implicitly to the thread.
