2

I haven't used the Semaphore strange enough...
Anyway I was reviewing some code using it and saw that unlike locks, a permit can be released by another thread (i.e. no ownership).
I looked into Concurrency in Action and it says (p.98):

The implementation has no actual permit objects....so a permit acquired by one thread can be released by another

I didn't notice this detail before and looked into an OS textbook I have that said (my emphasis):

When one process modifies the semaphore value no other process ....etc

So is this Java specific design decision? I mean that a semaphore is not owned by a thread.
Or am I misunderstanding the concept of semaphore?

Note: This is not a question of whether this is a good/bad design etc. I am just trying to be sure I understand the concept

Improve this question
2
  • What have you hidden in "etc."? Because it could be, "when a process modifies the semaphore value, no other process can modify it at the same time" Commented Feb 10, 2013 at 15:48
  • The semaphore idea is very old; older than Java, and older than synchronization primitives implemented in hardware. It was meant to be relatively easy to implement in software, and it was meant to be a versatile primitive that could be used in the implementation of higher-level synchronization objects. Mutual exclusion is just one of several useful things you can do with it. IMO, the main reason semaphore is interesting today is because it's been around so long, lots of published algorithms and textbook examples use it. Commented Oct 28, 2015 at 2:27

1 Answer 1

Reset to default
2

According to Wikipedia a Semaphore does not track which object is aquired/released but only the number. Hence "ownership" is not applicable here. Read the section "important observations"!

Hence there is no ownership. In this the regard the Java semaphore does the right thing. Also the Unix semaphore (see semop(2)) work this way.

However some textbooks seem to mix the terms "mutex", "lock" and "semaphores" quite liberally - you can judge the quality of that texts on your own.

EDIT:

I could not believe than Tannenbaum does not distinct between semaphores and mutexes, so I've searched the full citation of "When one process modifes the semaphore value[...]" and came up with stuff lie this (not knowing whether or not they are from Tannenbaum):

[...]the modifications to S in the P and V operations are executed indivisibly: that is when one process modifies the semaphore value, no other process can simultaneously modify that same semaphore value.[...]

Other quotes are so similar that I suspect copy&paste :-)

The point is: If your text reads the same, then you misunderstood the intention of the paragraph - it is not about "ownership", it is "only" about concurrent access. When multiple threads try to access one semaphore at exactly the same time the threads must be serialized and modification of the value (remember - there is only one value inside the semaphore for all resources) must be atomic.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

Well the textbook I mention is OS Concepts by Silberchatz which is quite well known.Same also is said in Tannenbaum.So why is wiki more reliable?
I'm not sure where the Wikipedia article refers to what you say?
@Flavio: The section "Important observations" basically says it by stating, that all processes must be trusted and must follow a protocol. The next paragraphs expand this. Also the section "Semaphore vs. mutex".
@A.H.:I don't have the english version of Tannenbaum (only of Silbechatz) so something could be lost in translation.But what you are saying I think is that, it is explicitely defined for a semaphore not to be acquired concurrently by 2 different processes/threads.But it is undefined whether a semaphore could be releashed by a different/process thread, making this an implementation detail.Am I getting what you say?
@Cratylus: Your wording is misleading: You don't "acquire/release" a semaphore, you increment/decrement (or: modify) it. "Acquire" already has the taste of ownership. That's what is required by Dijkstra's theory. Also many algorithms require that a semaphore does not imply "ownership". Think of a simple bounded print queue: The producer decrements the semaphore, the consumer increments it. Here "ownership" would spoil everything.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.