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.