<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>So...I do NOT understand all of this.</div><div><br></div><div><br></div><div>However, comparing the three implementations</div><div>and attempting to understand ours,</div><div>I am struck by the following</div><div><br></div><div> - Our broadcast seems ok, but </div><div> - our signal seems to wake everyone, </div><div> and then...they race a bit, </div><div> one will decide it is last, and </div><div> reset the event, but every prior waiter </div><div> is still woken. </div><div> </div><div> </div><div>Why not merge the following chunks:</div><div><br></div><div><br></div><div> WHILE (NOT alerted) AND (NOT waitDone) DO</div><div>.</div><div>.</div><div>.</div><div> 1 </div><div> EnterCriticalSection(conditionLock); </div><div> waitDone := (c.tickets # 0 AND c.counter # count); </div><div> LeaveCriticalSection(conditionLock); </div><div> </div><div> END; (* WHILE *) </div><div> </div><div> IF waitDone THEN </div><div> alerted := FALSE; </div><div> END; </div><div> </div><div> m.acquire(); </div><div> </div><div>2 </div><div> EnterCriticalSection(conditionLock); </div><div> DEC(c.waiters); </div><div> IF waitDone THEN esp. here. </div><div> DEC(c.tickets); </div><div> lastWaiter := (c.tickets = 0); </div><div> END; </div><div> LeaveCriticalSection(conditionLock);</div><div><br></div><div><br></div><div> That is, if we decrement tickets earlier </div><div> within the first critical section, </div><div> while we will still wake everyone, </div><div> only one will decide waitDone and the rest will keep looping. </div><div> </div><div> A downside of this, perhaps, is that waking all for Broadcast</div><div> might be a little slower.</div><div> </div><div> but more so, in both the "ptw32" (pthreads for win32) and Boost threads</div><div> implementations, they seem to deal with this differently than us,</div><div> and they each do about the same thing -- they use a counted semaphore.</div><div> </div><div> </div><div> In the boost case, it appears they duplicate the semaphore for every</div><div> notification generation, which seems expensive.</div><div><br></div><div> </div><div> Perhaps if they can guarantee some lifetimes, they don't need to duplicate it. </div><div> Or they can do their own reference counting? </div><div> </div><div> </div><div> jdk7 seems to looke like jdk6.</div><div> The code is gone in jdk8 and I can't easily find the delete in history.</div><div> </div><div> </div><div> The lock merging jdk does probably helps here too.</div><div> In fact they merge #1 and #2 above as a result.</div><div> But they still initially wake all threads for signal, not just broadcast.</div><div> </div><div> </div><div> There is also the problem that all the event waits</div><div> are followed by EnterCriticalSection (or jdk facsimile).</div><div> </div><div> - Jay</div><br><br><br><br><div><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: m3devel@elegosoft.com<br>Subject: RE: [M3devel] purported condition variable problems on Win32?<br>Date: Tue, 5 Jul 2016 08:26:36 +0000<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">Here is another implementation to consider:<div><br></div><div><a href="https://github.com/boostorg/thread/blob/develop/include/boost/thread/win32/condition_variable.hpp" target="_blank">https://github.com/boostorg/thread/blob/develop/include/boost/thread/win32/condition_variable.hpp</a></div><div><br></div><div> - Jay<br><br><br><div><hr id="ecxstopSpelling">From: jay.krell@cornell.edu<br>To: m3devel@elegosoft.com<br>Date: Tue, 5 Jul 2016 08:19:23 +0000<br>Subject: [M3devel] purported condition variable problems on Win32?<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr"><div> https://sourceforge.net/p/pthreads4w/code/ci/master/tree/README.CV</div><div><br></div><div> vs.</div><div><br></div><div>http://www.cs.wustl.edu/~schmidt/win32-cv-1.html</div><div> </div><div> vs.</div><div> </div><div> 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</div><div> </div><div> </div><div> I wrote this:</div><div> </div><div> PROCEDURE XWait(m: Mutex; c: Condition; act: Activation;</div><div> alertable: BOOLEAN) RAISES {Alerted} =</div><div> (* LL = m on entry and exit, but not for the duration</div><div> * see C:\src\jdk-6u14-ea-src-b05-jrl-23_apr_2009\hotspot\agent\src\os\win32\Monitor.cpp</div><div> * NOTE that they merge the user lock and the condition lock.</div><div> * http://www.cs.wustl.edu/~schmidt/win32-cv-1.html</div><div> * "3.3. The Generation Count Solution"</div><div> *)</div><div> </div><div><br></div><div> Do we have the problems described in README.CV?</div><div><br></div><div> </div><div> I haven't looked through the ACE code to see</div><div> to what extent they resemble solution 3.3, or if they</div><div> changed as a result of this discussion -- which I admit I don't understand</div><div>and haven't read closely.</div><div><br></div><div><br></div><div>Spurious wakeups are ok, though should be minimized.</div><div> </div><div><br></div><div>I'd still rather not drop pre-Vista support but I realize it becomes more interesting as time advances.</div><div><br></div><div> </div><div> Thank you,</div><div> - Jay</div> </div>
<br>_______________________________________________
M3devel mailing list
M3devel@elegosoft.com
https://m3lists.elegosoft.com/mailman/listinfo/m3devel</div></div> </div></div> </div></body>
</html>