Hi Eliot, all,

There's a bug, or rather an omission, in #releaseCriticalSection: causing the following examples unwind incorrectly:

Mutex new inspect critical: [self halt]

If you run the example in a workspace, a debugger and an inspector opens - please watch Mutex's 'owner' variable; then step into a few times to get right before sending #primitiveExitCriticalSection and terminate the debugger (in the newest images please use debugger's window menu -> terminate process); and observe the owner won't get cleared and will remain blocking the Mutex. Same behavior for Semaphores:

Semaphore forMutualExclusion inspect critical: [self halt]

Again, watch Semaphore's excessSignals variable in the Inspector, step into a few times until you stand before sending #signal - and terminate the debugged process (from the debuggers menu or from the Process Browser if you like) - the Semaphore won't recharge excessSignals back to 1.

The root cause is #releaseCriticalSection: doesn't account for terminating in this particular position of the computation. It can be fixed e.g. by adding an additional condition ('progressedIntoEnsure') - try the examples with the enclosed changeset; both Mutexes and Semaphores work ok now.

Best,

~~~
^[^    Jaromir

Sent from Squeak Inbox Talk
["Process-releaseCriticalSection.st"]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Process-releaseCriticalSection.st
Type: application/octet-stream
Size: 2737 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211221/faa167db/attachment.obj>