[threads-standard-discuss] bordeaux-mp Specification,1.7,1.8
Daniel Barlow,,,
dan at loaclhost.telent.net
Thu Jul 15 15:26:54 UTC 2004
Update of /usr/local/src/cvs/bordeaux-mp
In directory loaclhost.telent.net:/tmp/cvs-serv1400
Modified Files:
Specification
Log Message:
more bug fixes, courtesy Robert Strandh
Index: Specification
===================================================================
RCS file: /usr/local/src/cvs/bordeaux-mp/Specification,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- Specification 12 Jul 2004 23:41:50 -0000 1.7
+++ Specification 15 Jul 2004 15:26:51 -0000 1.8
@@ -211,20 +211,22 @@
2) A processes and removes all events that are available in C
3) When C is empty, A calls CONDITION-WAIT, which atomically
releases the lock and puts A to sleep on CV
-4) Loop back to step 1, for as long as processing should continue
+4) Wait to be notified; CONDITION-WAIT will acquire the lock again
+ before returning
+5) Loop back to step 2, for as long as processing should continue
When B generates an event E, it
1) acquires the lock guarding C
2) adds E to the channel
-3) releases the lock
-4) calls CONDITION-NOTIFY on CV to wake any sleeping process
+3) calls CONDITION-NOTIFY on CV to wake any sleeping process
+4) releases the lock
To avoid the "lost wakeup" problem, the implementation must guarantee
-that CONDITION-WAIT in process A atomically release the lock and
+that CONDITION-WAIT in process A atomically releases the lock and
sleeps. If this is not guaranteed there is the possibility that
process B can add an event and call CONDITION-NOTIFY between the lock
release and the sleep - in this case the notify call would not see A,
-which would be left sleeping despite there being events available.
+which would be left sleeping despite there being an event available.
make-condition-variable () [function]
More information about the Threads-standard-discuss
mailing list