[M3devel] A win32 thread test case

[Jay K]

ThreadPThread.m3 had the same narrow startup race condition. I fixed it.Again I'm not seeing commit mails.
On the larger matter:
I think there is a solution, in that, if you look atThreadPThread.m3 and how it uses Posix condition variables,in that it does a fair amount of the work itself,you can term this "condition within condition".

So I think maybe we can use the counting solutionand 1) merge the locks and/or 2) take the lock in Signal/Broadcast.

But I have to look at it more.


Specifically, in ThreadPThread.m3:
Broadcast:        WITH r = pthread_mutex_lock(t.mutex) DO <*ASSERT r=0*> END;        next := t.nextWaiter;        t.nextWaiter := NIL;        t.waitingOn := NIL;        WITH r = pthread_cond_signal(t.cond) DO <*ASSERT r=0*> END;
Signal:      WITH r = pthread_mutex_lock(t.mutex) DO <*ASSERT r=0*> END;      t.nextWaiter := NIL;      t.waitingOn := NIL;      WITH r = pthread_cond_signal(t.cond) DO <*ASSERT r=0*> END;

Becaise they signal while locked, we can implement this limitedform of condition variable, and then use the Modula-3 pthread logicusing that.

Make some sense?

Essentially we will have almost-posix condition variables,and exactly-posix mutexes, and then we can use just the pthread codeon top of that.

Almost-posix condition variable is a posix condition variable, exceptit is guaranteed you will call pthread_cond_signal with the samelock held as when you call pthread_cond_wait.

On a pthread system, the almost-posix condition variables and exactly-posixmutexes are just pass through to the underlying pthreads.

On a win32 system, an almost-posix condition variable is similarto what we have now, except, because we know this lock is held,"XWait" can remove some of the leave/enter cycles and remove race conditions.

Essentially we only need a "monitor", which is one lock and one condition variable.

OR, we can use "directed notification" where each thread has an event, and threads are linked through a "wait block" i.e. the condition. This should work well too. It depends on us owing CreateThread, which we already do.
 - Jay

From: jay.krell at cornell.edu
To: rodney.m.bates at acm.org; m3devel at elegosoft.com
Subject: RE: A win32 thread test case
Date: Sat, 30 Jul 2016 21:18:08 +0000




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.

  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 currentsituation. 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 usedby code that isn't away of you, that just creates threads in the "normal" wayfor their platform.

And then, either the current state, or a fix I have in mind, can be takenadvantage of to do "directed notify" w/o creating a kernel eventper 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 havea DllMain that allocates thread locals.

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 usethe Win32 condition variables presumably.I remain curious how the condition variables work there, i.e. we can'timplement them ourselves, but it is possible they either require kernelsupport 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
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20160731/d99afc13/attachment-0002.html>