Understanding semaphores

yotamoo picture yotamoo · May 3, 2012 · Viewed 10k times · Source

I am reading about semaphores in "Operating System Concepts" (for those of you who know it), and I thought I understood semaphores completely until I read this passage:

The critical aspect of semaphores is that they are executed atomically. We must guarantee that no two processes can execute wait and signal operations on the same semaphore at the same time.

And also:

If the hardware does not provide any special atomic instructions, we can employ any of the software solutions for the critical section problem, where critical sections consist of the wait and signal procedures.

This passage refers to the face to Signal and Wait operations must be atomic. I thought that the whole purpose of the semaphore was to let only one process in the critical section at any given time - if I have to use another algorithm (like the bakery algorithm), why do I also need the semaphore?

I realize my question might be confusing. If it is, its only because the subject is still vague to me, so even asking a question is a little hard.

Would love to read any clarifications...

Answer

Lucas Holt picture Lucas Holt · May 3, 2012

I think you're having trouble with the distinction between a semaphore and a mutex. A binary semaphore can be implemented in the same way as a mutex, but they are actually for different purposes. A semaphore protects a resource whereas a mutex strictly protects a block of code. The distinction is often subtle.

With semaphores you get into variations like counting semaphores so the idea that only one process can access a resource isn't always true. You may want to block writes to one process or thread, but allow reads from multiple (reader/writer locks).

I suggest you look at the wikipedia article on the subject. It's actually quite good.
http://en.wikipedia.org/wiki/Semaphore_(programming)