[M3devel] A win32 thread test case

[Jay]

Right. But by merging at the application layer, they can be merged in the implementation as well. 
But right, we can't.

I don't expect other languages to use the m3 runtime but for other languages to call into m3 code, which uses the m3 runtime.

The other languages all Interoperate with each other: C++, C#, Java. They can all call into each other without having to know they are and without using other than native platform thread creation. For example on Windows they can all be in-proc COM servers.
It is a flaw to require other than platform native thread creation.

 - Jay

> On Jul 31, 2016, at 5:42 PM, "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:
> 
> 
> 
>> On 07/30/2016 04:18 PM, Jay K wrote:
>> I fixed the new_slots problem.
>> 
>> 
>> I agree there are problems here.
>>   I think Java got away with a similar implementation
>>   because their interface is a bit different.
>>   i.e. the lock and condition are merged, and/or notification
>>   requires the caller to take the lock. We can't do this.
>>   We allow signal/broadcast w/o holding a lock.
>>   We'd have to resort to a global lock I guess.
> 
> Ah, I think I am finally getting what you mean by merging the mutex and
> Condition.  Java's primitives merge these at the level the application
> sees, not inside the implementation.  Off hand, I think this might be more
> awkward for some use cases, but anyway, we can't change the semantics of
> our primitives.
> 
>> 
>>   I suspect nobody else uses this solution.
>> 
>> 
>> I believe we can solve it better and worse than others.
>> 
>> 
>> Most libraries do not have their own "CreateThread" function.
>> That is, most libraries let you call pthread_create or Win32 CreateThread,
>> and the library will interoperate with any thread that comes its way.
>> And most libraries don't seem to use thread locals in their solution.
>> By "most libraries", I mean the pthreads on win32 package and Boost.
>> 
>> 
>> Modula-3 isn't clearly this way. This isn't great, but it is the current
>> situation. I believe it is fixable.
>> That is, Modula-3 I believe requires using its library to create threads.
>> This is not great for interoperation. You want to be able to be used
>> by code that isn't away of you, that just creates threads in the "normal" way
>> for their platform.
>> 
>> 
>> And then, either the current state, or a fix I have in mind, can be taken
>> advantage of to do "directed notify" w/o creating a kernel event
>> per wait or notify, like other solutions do.
>> 
>> 
>> As to the fix, to not require threads go through our "CreateThread",
>> I believe on Windows (which is all that is relevant here), we should have
>> a DllMain that allocates thread locals.
> 
> While it is appealing from a performance point of view, I doubt directly using
> other synchronization primitives from other libraries can be made to work.  We
> have a number of differences.  Threads, Mutexs, and Conditions, all three,
> are M3 objects, and can be subtyped in Modula-3's object subtype semantics.
> Even without this, they all contain various properties that other libraries'
> objects almost certainly don't.  They are traced and garbage-collected.  Threads,
> at least, actively participate in the GC implementation.  The M3 Fork and Join
> mechanism, the Alert mechanism, and the exception handling implementation
> mechanism are all intertwined.  There are some automatic cleanup things happening.
> There are just too many differences.
> 
> 
>> We can only easily have a DllMain if we are a .dll.
>> Or we can use __declspec(thread).
>> __declspec(thread) works if the .exe is statically linked to the exe or the dll,
>> or on Vista and newer, but not in a .dll loaded by LoadLibrary prior to Vista.
>> Perhaps that is good enough.
>> 
>> 
>> If we require Vista then we can just drop a bunch of our code and use
>> the Win32 condition variables presumably.
>> I remain curious how the condition variables work there, i.e. we can't
>> implement them ourselves, but it is possible they either require kernel
>> support or are well beyond our abilities.
>> 
>> 
>> 
>>  - Jay
>> 
>> 
>> 
>> 
>> > Date: Thu, 28 Jul 2016 15:00:45 -0500
>> > From: rodney_bates at lcwb.coop
>> > To: m3devel at elegosoft.com; jay.krell at cornell.edu
>> > Subject: A win32 thread test case
>> >
>> > I have attached a test case program designed to expose one of the bugs
>> > I think I see in ThreadWin32.m3. It runs correctly on AMD64_LINUX.
>> > I expect it to fail on Windows, but don't have a Windows machine I
>> > can try it on.
>> >
>> > Anybody willing to try it? It's a self-contained Main module. Just
>> > compile and run it. It will announce what it finds.
>> >
>> >
>> > --
>> > Rodney Bates
>> > rodney.m.bates at acm.org
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org