[M3devel] ThreadBase/RunThread

[Jay K]

I think another problem is that pthread_setspecific_activations + LOCK in the same function might not mix.

pthread_setspecific_activations only occurs twice in the code base, very special.

It should be left alone.

 

 - Jay

 


CC: m3devel at elegosoft.com
From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Subject: Re: ThreadBase/RunThread
Date: Sun, 8 Nov 2009 19:08:12 -0500





There should be no traced references manipulated in ThreadBase.


In RunThread, self is kept live by simply holding it on the stack.


You will probably have trouble eliminating the slots array.  We need a global to hang on to the traced Thread.T.  How else do you propose to associate untraced pthreads with their traced Thread.T?


On 8 Nov 2009, at 18:05, Jay K wrote:

ThreadBase/RunThread -- something seems a little off to me here.
 
 
I merged the functions.
Stuff is supposed to work asif there is arbitrary inlining.
 At least until/unless we get a pragma to mark a function as not inlinable or a direct language feature analogous to "volatile" to preserve locals -- currently inserting try does it but that's an implementation detail I think.
 
 
However, I wonder, in taking the address of "xx", isn't ThreadBase a bit..gambling?
You know, the traced references might be before or after xx in the stack, so xx might not cover it.
 
 
The code is safe because the only traced reference is "self" which also is reachable via slots.
 
 
In particular I'm trying to link Activation<=>T and introduce allThreadsTraced analogous to allThreads -- a global list of all threads, covering their traced part.
That way AssignSlots/FreeSlots and the slots lock would go away.
Removing locks seems like a good thing in general.
Overall space consumption wouldn't be much different, I'd trade an array of pointers, one pointer per thread, for two pointers embedded in each thread plus a global pointer. But the ability to fetch Self() faster or RunThread to block on less or no locking would be good -- not that Self() is used much anymore.
 
 
I keep seeing strange failures and I wonder if taking away the slots reference leaves me with insufficient reference.
Or maybe I'm breaking it some other way.
 
I tried building up allThreadsTraced earlier, while stackbase isn't settable, and have code watch for stackbase = NIL but still no luck.
 
 
I'll try more later...
 
 
 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091109/4a315bc8/attachment-0002.html>