References

[bencoman]

Thought a placeholder to share reference material might be useful.

Converting this LaTeX book to Pillar could provide a good starting point. Anyone got tips on converting?
http://greenteapress.com/wp/semaphores/
https://github.com/AllenDowney/LittleBookOfSemaphores
Although I should say I haven't read through it. I just always meant to since I saw it referenced a lot.

Some significant commentary that has shaped my thinking over the years...

https://barrgroup.com/Embedded-Systems/How-To/RTOS-Mutex-Semaphore

• Myth: Mutexes and Semaphores are Interchangeable
• Priority Inversion
• The History of Semaphores and Mutexes

https://blog.feabhas.com/2009/09/mutex-vs-semaphores-%E2%80%93-part-1-semaphores/

• "A mutex is really a semaphore with value 1" No, no and no again.
• Issues: Accidental release, Recursive Deadlock, Deadlock through Task Death, Priority Inversion
• Semaphore as a signal

https://blog.feabhas.com/2009/09/mutex-vs-semaphores-%E2%80%93-part-2-the-mutex/

• the principle of ownership addressing Semaphore issues, death detection
• Review of some OS APIs

https://blog.feabhas.com/2009/10/mutex-vs-semaphores-%E2%80%93-part-3-final-part-mutual-exclusion-problems/

• Circular Deadlock, Priority Ceiling Protocol, Non-cooperation, the Monitor

http://www.geeksforgeeks.org/mutex-vs-semaphore/

• Producer-consumer problem
• Mutex is locking mechanism, Semaphore is signaling mechanism

[Ducasse]

Thanks I read some little book of semaphores.
Now the booklet is to talk about Pharo not about concurrency in general.
I read long time ago and could not understand :) Myth: Mutexes and Semaphores are Interchangeable

[bencoman]

could not understand :) Myth: Mutexes and Semaphores are Interchangeable

I think it comes down the statement in part 2...

mutex is similar to the principles of the binary semaphore with one significant difference: the principle of ownership.

Ownership is the simple concept that when a task locks (acquires) a mutex only it can unlock (release) it. If a task tries to unlock a mutex it hasn’t locked (thus doesn’t own) then an error condition is encountered and, most importantly, the mutex is not unlocked. If the mutual exclusion object doesn’t have ownership then, irrelevant of what it is called, it is not a mutex.

which you can see here...

Object subclass: #Mutex
	instanceVariableNames: 'semaphore owner'
	classVariableNames: ''
	package: 'Kernel-Processes'

Due to ownership a mutex cannot be used for synchronization due to lock/unlock pairing. This makes the code cleaner by not confusing the issues of mutual exclusion with synchronization.

In general, mutexes are used for controlling access to shared resources.
Semaphores are used for synchronisation that code-A executes before code-B.

[Ducasse]

Ok sorry I was confused. Yes Mutex handled recursive self calls. They were called RecursionLock in VisualWorks and I always forget.

[Ducasse]

And indeed Mutexes are not interchangeable with Semaphores.