[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