Issue 94: fixed a bad bug in #critical: unwind mechanism. jv
authorJan Vrany <jan.vrany@fit.cvut.cz>
Mon, 11 Dec 2017 11:36:00 +0000
branchjv
changeset 23094 664a6370e264
parent 23093 9c9fa5a584bb
child 23095 a5d786f8ebc6
Issue 94: fixed a bad bug in #critical: unwind mechanism. When unwiding a #critical: frame, there are two (only two?) cases: 1. the critical section is executing aand being unwound 2. the process calling #critical: is waiting inside #acquire... for some other process to release it. In the first case we have to call `#release`, in the second we MUST NOT since other process owns the lock. To distinguish, we check whether we own the lock or not by self owner == Processor activeProcess
RecursionLock.st
--- a/RecursionLock.st	Tue Nov 21 21:31:18 2017 +0000
+++ b/RecursionLock.st	Mon Dec 11 11:36:00 2017 +0000
@@ -377,11 +377,25 @@
 
 unwindHandlerInContext:aContext
     aContext selector == #critical: ifTrue:[
-        ^ [ self release ]
+        ^ [
+            "/ When unwiding a #critical: frame, there are two (only two?)
+            "/ cases:
+            "/
+            "/ 1. the critical section is executing aand being unwound
+            "/ 2. the process calling #critical: is waiting inside #acquire...
+            "/    for some other process to release it.
+            "/
+            "/ In the first case we have to call #release, in the second
+            "/ we MUST NOT since other process owns the lock.
+            "/ To distinguish, we check whether we own the lock or not
+            "/ by `self owner == Processor activeProcess`.
+            self owner == Processor activeProcess ifTrue:[ self release ].
+          ]
     ].
     self shouldNeverBeReached.
 
     "Created: / 31-08-2017 / 10:11:45 / Jan Vrany <jan.vrany@fit.cvut.cz>"
+    "Modified (format): / 11-12-2017 / 11:33:47 / Jan Vrany <jan.vrany@fit.cvut.cz>"
 ! !
 
 !RecursionLock methodsFor:'waiting'!