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?

Reply via email to