Ben would you not be interested to write a little chapter on concurrency because we would all benefit from it. I can help but I'm pretty bad with concurrency. I'm sure that doing that we will find a lot of things to improve in Pharo :) Stef Le 5/1/16 18:15, Ben Coman a écrit :
On Tue, Jan 5, 2016 at 11:59 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-01-05 16:06 GMT+01:00 Ben Coman <btc@openinworld.com>:
btw I have this growing suspicion that we should eliminate Semaphore>>critical: and Semaphore>>forMutualExclusion. Semaphores on their own should *not* provide a facility for to protect critical regions since they suffer from accidental release [1] due to *lack*of*ownership*.
I have same feeling when analyse problem of critical: implementation. But I not think that Semaphore>>forMutualExclusion is bad. But Semaphore>>forMutualExclusion *encourages* people to believe semaphores can be used *on*their*own* for mutual exclusion, when they *shouldn't*. You *must* add ownership. If the mutual exclusion object doesnât have ownership then, irrelevant of what it is called, it is not a mutex!!! [1].
"Strictly speaking [2]... -- A mutex is *locking* mechanism used to synchronize access to a resource. Only one task (can be a thread or process based on OS abstraction) can acquire the mutex. It means there is *ownership* associated with mutex, and only the owner can release the lock (mutex). -- A semaphore is *signaling* mechanism (âI am done, you can carry onâ kind of signal). For example, if you are listening songs (assume it as one task) on your mobile and at the same time your friend calls you, an interrupt is triggered upon which an interrupt service routine (ISR) signals the call processing task to wakeup
It is common case that semaphore "free" by default. With an implementation like.. Semaphore>>forMutualExclusion ^self new signal
we don't gain a lot, and its a misleading convenience method since its doesn't provide the proper facility for mutual exclusion (and I do conflate mutual exclusion == mutex). Indeed, "Semaphore forMutualExclusion + roll your ownership management + problems since you weren't aware you needed to roll your own ownership management" is not more convenient than "Mutex new"
If you want to keep a convenience method for a pre signalled Semaphore, then we could provide something like "Semaphore newSignalled"
And this name is explicitly said about this. Actually no. It explicitly says it provides mutual exclusion - which without ownership, it does not. It only implicitly provides a pre-signalled Semaphore - you have to *know* of look at the source.
[1] https://blog.feabhas.com/2009/09/mutex-vs-semaphores-%E2%80%93-part-2-the-mu... [2] http://www.geeksforgeeks.org/mutex-vs-semaphore/
cheers -ben