[M3devel] purported condition variable problems on Win32?

[Jay K]

So...I do NOT understand all of this.

However, comparing the three implementationsand attempting to understand ours,I am struck by the following
 - Our broadcast seems ok, but  - our signal seems to wake everyone,    and then...they race a bit,    one will decide it is last, and    reset the event, but every prior waiter    is still woken.       Why not merge the following chunks:

    WHILE (NOT alerted) AND (NOT waitDone) DO... 1       EnterCriticalSection(conditionLock);         waitDone := (c.tickets # 0 AND c.counter # count);       LeaveCriticalSection(conditionLock);      END; (* WHILE *)      IF waitDone THEN       alerted := FALSE;     END;      m.acquire();  2     EnterCriticalSection(conditionLock);       DEC(c.waiters);       IF waitDone THEN   esp. here.         DEC(c.tickets);         lastWaiter := (c.tickets = 0);       END;     LeaveCriticalSection(conditionLock);

 That is, if we decrement tickets earlier  within the first critical section,   while we will still wake everyone,  only one will decide waitDone and the rest will keep looping.   A downside of this, perhaps, is that waking all for Broadcast might be a little slower.  but more so, in both the "ptw32" (pthreads for win32) and Boost threads implementations, they seem to deal with this differently than us, and they each do about the same thing -- they use a counted semaphore.   In the boost case, it appears they duplicate the semaphore for every notification generation, which seems expensive.
  Perhaps if they can guarantee some lifetimes, they don't need to duplicate it.  Or they can do their own reference counting?    jdk7 seems to looke like jdk6. The code is gone in jdk8 and I can't easily find the delete in history.    The lock merging jdk does probably helps here too.  In fact they merge #1 and #2 above as a result.  But they still initially wake all threads for signal, not just broadcast.     There is also the problem that all the event waits  are followed by EnterCriticalSection (or jdk facsimile).    - Jay



From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: RE: [M3devel] purported condition variable problems on Win32?
Date: Tue, 5 Jul 2016 08:26:36 +0000




Here is another implementation to consider:
https://github.com/boostorg/thread/blob/develop/include/boost/thread/win32/condition_variable.hpp
 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Tue, 5 Jul 2016 08:19:23 +0000
Subject: [M3devel] purported condition variable problems on Win32?




 https://sourceforge.net/p/pthreads4w/code/ci/master/tree/README.CV
 vs.
http://www.cs.wustl.edu/~schmidt/win32-cv-1.html  vs.  https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/WIN32/ThreadWin32.m3?rev=1.210.2.1;content-type=text%2Fplain   I wrote this:  PROCEDURE XWait(m: Mutex; c: Condition; act: Activation;                alertable: BOOLEAN) RAISES {Alerted} =  (* LL = m on entry and exit, but not for the duration   * see C:\src\jdk-6u14-ea-src-b05-jrl-23_apr_2009\hotspot\agent\src\os\win32\Monitor.cpp   * NOTE that they merge the user lock and the condition lock.   * http://www.cs.wustl.edu/~schmidt/win32-cv-1.html   *   "3.3. The Generation Count Solution"   *)   
 Do we have the problems described in README.CV?
  I haven't looked through the ACE code to see to what extent they resemble solution 3.3, or if they changed as a result of this discussion -- which I admit I don't understandand haven't read closely.

Spurious wakeups are ok, though should be minimized. 
I'd still rather not drop pre-Vista support but I realize it becomes more interesting as time advances.
  Thank you,  - Jay 		 	   		  

_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://m3lists.elegosoft.com/mailman/listinfo/m3devel 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20160707/3fd7f5be/attachment-0003.html>