<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>I fixed the new_slots problem.</div><div><br></div><div><br></div><div>I agree there are problems here.</div><div> I think Java got away with a similar implementation</div><div> because their interface is a bit different.</div><div> i.e. the lock and condition are merged, and/or notification</div><div> requires the caller to take the lock. We can't do this.</div><div> We allow signal/broadcast w/o holding a lock.</div><div> We'd have to resort to a global lock I guess.</div><div><br></div><div><br></div><div> I suspect nobody else uses this solution.</div><div><br></div><div><br></div><div>I believe we can solve it better and worse than others.</div><div><br></div><div><br></div><div>Most libraries do not have their own "CreateThread" function.</div><div>That is, most libraries let you call pthread_create or Win32 CreateThread,</div><div>and the library will interoperate with any thread that comes its way.</div><div>And most libraries don't seem to use thread locals in their solution.</div><div>By "most libraries", I mean the pthreads on win32 package and Boost.</div><div><br></div><div><br></div><div>Modula-3 isn't clearly this way. This isn't great, but it is the current</div><div>situation. I believe it is fixable.</div><div>That is, Modula-3 I believe requires using its library to create threads.</div><div>This is not great for interoperation. You want to be able to be used</div><div>by code that isn't away of you, that just creates threads in the "normal" way</div><div>for their platform.</div><div><br></div><div><br></div><div>And then, either the current state, or a fix I have in mind, can be taken</div><div>advantage of to do "directed notify" w/o creating a kernel event</div><div>per wait or notify, like other solutions do.</div><div><br></div><div><br></div><div>As to the fix, to not require threads go through our "CreateThread",</div><div>I believe on Windows (which is all that is relevant here), we should have</div><div>a DllMain that allocates thread locals.</div><div><br></div><div><br></div><div>We can only easily have a DllMain if we are a .dll.</div><div>Or we can use __declspec(thread).</div><div>__declspec(thread) works if the .exe is statically linked to the exe or the dll,</div><div>or on Vista and newer, but not in a .dll loaded by LoadLibrary prior to Vista.</div><div>Perhaps that is good enough.</div><div><br></div><div><br></div><div>If we require Vista then we can just drop a bunch of our code and use</div><div>the Win32 condition variables presumably.</div><div>I remain curious how the condition variables work there, i.e. we can't</div><div>implement them ourselves, but it is possible they either require kernel</div><div>support or are well beyond our abilities.</div><div><br></div><div><br></div><div><br></div><div> - Jay</div><br><br><br><br><div>> Date: Thu, 28 Jul 2016 15:00:45 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com; jay.krell@cornell.edu<br>> Subject: A win32 thread test case<br>> <br>> I have attached a test case program designed to expose one of the bugs<br>> I think I see in ThreadWin32.m3. It runs correctly on AMD64_LINUX.<br>> I expect it to fail on Windows, but don't have a Windows machine I<br>> can try it on.<br>> <br>> Anybody willing to try it? It's a self-contained Main module. Just<br>> compile and run it. It will announce what it finds.<br>> <br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br></div> </div></body>
</html>