> On 05 Jan 2016, at 11:17, Denis Kudriashov <[email protected]> wrote: > > Hello. > > Here is Monitor code: > > critical: aBlock > ^[ > self enter. > aBlock value] > ensure: [self exit]. > > Now look at Semaphore comment and implementation: > > We need to catch eventual interruptions very carefully. > The naive approach of just doing, e.g.,: > self wait. > aBlock ensure: [self signal]. > will fail if the active process gets terminated while in the wait. > > However, the equally naive: > [self wait. > aBlock value] ensure: [self signal]. > will fail too, since the active process may get interrupted while > entering the ensured block and leave the semaphore signaled twice. > > critical: aBlock > | blockValue caught | > caught := false. > [ > caught := true. > self wait. > blockValue := mutuallyExcludedBlock value > ] ensure: [caught ifTrue: [self signal]]. > ^blockValue > > So Monitor can be corrupted when process which enters critical section will > be terminated. "Ensure block" can signal mutex which was not in waiting mode. > Which means that next critical call in another Process will be not guarded. > > What you think? Is my investigation right? > > I look at users of Monitor. Most time it is used like Mutex. Only #critical: > method is used. So Monitor can be replaced by Mutex at that places. And > possible problem will be fixed. > > SharedQueue is classic example for Monitor usage. Interesting is anybody got > problems with it?
You may have a point there. Although the monitor uses a Semaphore #forMutualExclusion, which is a semaphore with one signal. So the case where the semaphore gets signalled without #wait is less likely I think. What I don’t quite understand is why Monitor doesn’t use Semaphore>>critical:. If it did that, then there wouldn’t be a problem. The problem only exists because #wait and #signal are explicitly sent by the monitor.
