CODEWITHSUNDEEP
javamultithreadingconcurrencysemaphore
Cratylus
Cratylus

Reputation: 54074

Semaphore implementation in Java

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

Upvotes: 2

Views: 1535

Answers (1)

A.H.
A.H.

Reputation: 66223

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.

Upvotes: 2

Related Questions