An alternative approach is to use a queue in place of the semaphore.
When this is done the interrupt routine can capture the data associated
with the peripheral event and send it on a queue to the task.
The task unblocks when data becomes available on the queue,
retrieves the data from the queue, then performs any data processing that is required.
This second scheme permits interrupts to remain as short as possible, with all post processing instead occurring within a task.
See the Semaphores/Mutexes section of the user documentation for a list of semaphore related API functions.
Searching the files in the FreeRTOS/Demo/Common/Minimal directory will reveal multiple examples of their usage.
Note that interrupts must NOT use API functions that do not end in "FromISR" .
Using a semaphore to synchronise a task with an interrupt.
The interrupt only ever 'gives' the semaphore,
while the task only ever 'takes' the semaphore.
http://stackoverflow.com/questions/62814/difference-between-binary-semaphore-and-mutex
Their synchronization semantics are very different:
mutexes allow serialization of access to a given resource i.e. multiple threads wait for a lock,
one at a time and as previously said, the thread owns the lock until it is done:
only this particular thread can unlock it.a binary semaphore is a counter with value 0 and 1: a task blocking on it until any task does a sem_post.
The semaphore advertises that a resource is available, and it provides the mechanism
to wait until it is signaled as being available.
As such one can see a mutex as a token passed from task to tasks
and a semaphore as traffic red-light (it signals someone that it can proceed).
On Windows, there are two differences between mutexes and binary semaphores:
A mutex can only be released by the thread which has ownership,
i.e. the thread which previously called the Wait function, (or which took ownership when creating it).
A semaphore can be released by any thread.A thread can call a wait function repeatedly on a mutex without blocking.
However, if you call a wait function twice on a binary semaphore
without releasing the semaphore in between, the thread will block.
In windows the difference is as below.
MUTEX: process which successfully executes wait has to execute asignal and vice versa.
BINARY SEMAPHORES: Different processes can execute wait or signal operation on a semaphore.
A Mutex controls access to a single shared resource.
It provides operations to acquire() access to that resource and release() it when done.
A Semaphore controls access to a shared pool of resources.
It provides operations to Wait() until one of the resources in the pool becomes available,
and Signal() when it is given back to the pool.
When number of resources a Semaphore protects is greater than 1, it is called a Counting Semaphore.
When it controls one resource, it is called a Boolean Semaphore.
A boolean semaphore is equivalent to a mutex.
Thus a Semaphore is a higher level abstraction than Mutex.
A Mutex can be implemented using a Semaphore but not the other way around.
http://www.geeksforgeeks.org/mutex-vs-semaphore/
Strictly speaking, a mutex is locking mechanism used to synchronize access to a resource.
Only one task (can be a thread or process based on OS abstraction) can acquire the mutex.
It means there will be ownership associated with mutex, and only the owner can release the lock (mutex).
Semaphore is signaling mechanism (“I am done, you can carry on” kind of signal).
For example, if you are listening songs (assume it as one task) on your mobile
and at the same time your friend called you, an interrupt will be triggered upon
which an interrupt service routine (ISR) will signal the call processing task to wakeup.
http://www.geeksforgeeks.org/mutex-vs-semaphore/
Mutex vs Semaphore
What are the differences between Mutex vs Semaphore?
When to use mutex and when to use semaphore?
Concrete understanding of Operating System concepts is required to design/develop smart applications.
Our objective is to educate the reader on these concepts and learn from other expert geeks.
As per operating system terminology, the mutex and semaphore are kernel resources that provide synchronization services
(also called as synchronization primitives).
Why do we need such synchronization primitives? Won’t be only one sufficient?
To answer these questions, we need to understand few keywords.
Please read the posts on atomicity and critical section.
We will illustrate with examples to understand these concepts well, rather than following usual OS textual description.
The producer-consumer problem:
Note that the content is generalized explanation. Practical details will vary from implementation.
Consider the standard producer-consumer problem.
Assume, we have a buffer of 4096 byte length.
A producer thread will collect the data and writes it to the buffer.
A consumer thread will process the collected data from the buffer.
Objective is, both the threads should not run at the same time.
Using Mutex:
A mutex provides mutual exclusion, either producer or consumer can have the key (mutex) and proceed with their work.
As long as the buffer is filled by producer, the consumer needs to wait, and vice versa.
At any point of time, only one thread can work with the entire buffer. The concept can be generalized using semaphore.
Using Semaphore:
A semaphore is a generalized mutex. In lieu of single buffer, we can split the 4 KB buffer into four 1 KB buffers (identical resources).
A semaphore can be associated with these four buffers. The consumer and producer can work on different buffers at the same time.
Misconception:
There is an ambiguity between binary semaphore and mutex.
We might have come across that a mutex is binary semaphore.
But they are not! The purpose of mutex and semaphore are different.
May be, due to similarity in their implementation a mutex would be referred as binary semaphore.
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
