semaphores... three diagrams...

Hi,

Please make me understand the state diagrams in counting and mutex semaphores...

as why the count is also increasing and decreasing in same available state..

And also something similar in mutex also...

Regards,

Simran..

Also,

What is meant by pre- empted...

Regards,

Simran..

Hi,

Pre-empted Kernel or Pre-empted scheduling , means that the scheduler gives each process (task) a certain amount of time "quantum" to run and then switches to another process, while in Non-prempted (Co-operative) Scheduling, the running process has to be blocked for the CPU to be allocated to another process.

I have tried to explain and give the answer of your question , just go through the attachment .....



Take care and good bye ......

Counting semaphore is used to count how many times the semaphore is accessed. the value gets incremented and decremented.

The best example is any licenced software.
If you have licence for 10 people connected in a network or internet, If one user starts using the software the count gets incremented by 1. As the number the users increase the registre increments the variable till 10. If 11th person wants to use the system then he is not given permission. If 1 person releases the software then it decrements the count by 1 and allows a new request to be processed who is in the queue.
So counting semaphore works in the same way. So you can see increment and decrement in counting semaphore.

Mutex semaphore. is a concept safe guarding the permission and the content which can be accessed or modified by other application forcefully.
Eg. In your house if you are reading a paper, and your younger brother or sisters come and ask you the paper, you dont give them and refuse, for the reason that they have lower priority than you. but you cannot refuse if your father or mother is asking. you may have to give them even if you dont want. So sometimes what you do, in order to protect the topic you carry the paper with you without leaving the paper somewhere, so that no one access it without your permission. Once you are done then you release the paper and give permission to who ever wants it.

Mutex is protecting the variable from other interrupts from accessing the variable and modifying it.

The following is not my content, it is cut and paste, but it does a very good job of explaining the difference between mutexes and semaphores:

The Myth: Mutexes and semaphores are similar--even interchangeable--operating system primitives.

The Truth: Mutexes and semaphores should always be used for distinct purposes, and should thus feature distinct APIs. (My recommendations to RTOS vendors are at the end.)

The cause of the confusion between mutexes and semaphores is historical, dating all the way back to the 1974 invention of the semaphore by Djikstra. Prior to that date, the interrupt-safe task synchronization and signaling mechanisms known to computer scientists were not efficiently scalable for use by more than two tasks. Dijkstra's scalable semaphore could be used for task synchronization (including mutual exclusion) as well as signaling.

After the introduction of commercial real-time operating systems (beginning with VRTX, ca. 1980) and the publication of a 1990 paper on priority inheritance protocols it became apparent that mutexes needed to be more than just semaphores with a binary value. Because of the possibility of unbounded priority inversion, which would break RMA assumptions, ordinary semaphores cannot be used for mutual exclusion.

Many bad sources of information add to the general confusion by introducing the alternate names binary semaphore for mutex and counting semaphore. The current wikipedia entry for semaphore is a prime example.

The correct and appropriate solution is a distinct set of RTOS primitives: one for semaphores and another for mutexes. Mutexes must prevent unbounded priority inversion. The APIs for semaphores and mutexes should be as distinct as possible, as their use is quite different.