--- a/JavaMonitor.st Mon Jun 19 14:41:39 2017 +0200
+++ b/JavaMonitor.st Mon Jun 19 14:44:52 2017 +0200
@@ -119,26 +119,27 @@
decrement
"owning process released monitor, let's lower our counter so we know how many times
we have to release it"
-
+
"/ the lock is probably not helping here to protect against problems with
"/ increment/decrement:
- "/ the write-access (in reinitCOunter) will be either done before incrementing/decrementing or after.
- "/ if after, everything is ok;
+ "/ the write-access (in reinitCounter) will be either done before incrementing/decrementing or after.
+ "/ if after, everything is OK;
"/ if before, the decremented value will be zero, which is probably wrong.
"/ without the critical region, we might also get possible inconsistencies:
"/ if written before, the counter will drop to zero
- "/ if written in-between, the counter wil ahve the old value decremented;
- "/ if written afterwards, everything is ok.
+ "/ if written in-between, the counter will have the old value decremented;
+ "/ if written afterwards, everything is OK.
"/ so, the lock should be really elsewhere, making sure that noone will count
- "/ the monitor at-all and the monitor is reininialized without anyone depending on the
+ "/ the monitor at-all and the monitor is reinitialized without anyone depending on the
"/ count at all.
"/ but then, no critical section is needed in reinitCounter!!.
instVarAccess critical: [ count := count - 1 ].
"Created: / 22-11-2011 / 10:49:33 / Marcel Hlopko <hlopkmar@fel.cvut.cz>"
+ "Modified (comment): / 19-06-2017 / 14:39:51 / mawalch"
!
disableWait
@@ -163,19 +164,19 @@
!
increment
- "owning process entered monitor again (recursion ...), lets raise our counter so we know how many times
- do we have to release it"
-
+ "owning process entered monitor again (recursion ...), let's raise our counter so we know how many times
+ we have to release it"
+
"/ the lock is probably not helping here to protect against problems with
"/ increment/decrement:
- "/ the write-access (in reinitCOunter) will be either done before incrementing/decrementing or after.
- "/ if after, everything is ok;
+ "/ the write-access (in reinitCounter) will be either done before incrementing/decrementing or after.
+ "/ if after, everything is OK;
"/ if before, the decremented value will be zero, which is probably wrong.
"/ without the critical region, we might also get possible inconsistencies:
"/ if written before, the counter will drop to zero
- "/ if written in-between, the counter wil ahve the old value decremented;
- "/ if written afterwards, everything is ok.
+ "/ if written in-between, the counter will have the old value decremented;
+ "/ if written afterwards, everything is OK.
"/ so, the lock should be really elsewhere, making sure that noone will count
"/ the monitor at-all and the monitor is reininialized without anyone depending on the
@@ -186,6 +187,7 @@
"Created: / 22-11-2011 / 10:49:07 / Marcel Hlopko <hlopkmar@fel.cvut.cz>"
"Modified: / 27-08-2012 / 10:42:11 / Jan Vrany <jan.vrany@fit.cvut.cz>"
+ "Modified (comment): / 19-06-2017 / 14:37:49 / mawalch"
!
owningProcess: aProcess
@@ -216,40 +218,41 @@
!
reinitCounter
- "owning process is different from previous, lets start counting from beginning"
+ "owning process is different from previous, let's start counting from beginning"
"/ the lock is probably not helping here to protect against problems with
"/ increment/decrement:
"/ the write-access here will be either done before incrementing/decrementing or after.
- "/ if after, everything is ok;
+ "/ if after, everything is OK;
"/ if before, the decremented value will be zero, which is probably wrong.
"/ without the critical region, we might also get possible inconsistencies:
"/ if written before, the counter will drop to zero
- "/ if written in-between, the counter wil ahve the old value decremented;
- "/ if written afterwards, everything is ok.
-
+ "/ if written in-between, the counter will have the old value decremented;
+ "/ if written afterwards, everything is OK.
+
"/ so, the lock should be really elsewhere, making sure that noone will count
"/ the monitor at-all and the monitor is reininialized without anyone depending on the
"/ count at all.
"/ but then, no critical section is needed!!.
-
+
instVarAccess critical: [ count := 1 ].
"Created: / 22-11-2011 / 10:51:09 / Marcel Hlopko <hlopkmar@fel.cvut.cz>"
+ "Modified (comment): / 19-06-2017 / 14:39:04 / mawalch"
!
-reinitCounter: newCount
+reinitCounter: newCount
"/ the lock is probably not helping here to protect against problems with
"/ increment/decrement:
"/ the write-access here will be either done before incrementing/decrementing or after.
- "/ if after, everything is ok;
+ "/ if after, everything is OK;
"/ if before, the decremented value will be zero, which is probably wrong.
"/ without the critical region, we might also get possible inconsistencies:
"/ if written before, the counter will drop to zero
- "/ if written in-between, the counter wil ahve the old value decremented;
- "/ if written afterwards, everything is ok.
+ "/ if written in-between, the counter will have the old value decremented;
+ "/ if written afterwards, everything is OK.
"/ so, the lock should be really elsewhere, making sure that noone will count
"/ the monitor at-all and the monitor is reininialized without anyone depending on the
@@ -259,6 +262,7 @@
instVarAccess critical: [ count := newCount ].
"Created: / 22-11-2011 / 13:00:51 / Marcel Hlopko <hlopkmar@fel.cvut.cz>"
+ "Modified (format): / 19-06-2017 / 14:40:09 / mawalch"
!
removeProcess: aProcess