[M3devel] ThreadBase/RunThread

[Jay K]

(truncated)

 

Oh, I think I get it:

 

Index: ThreadPThread.m3
===================================================================
RCS file: /usr/cvs/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThread.m3,v
retrieving revision 1.167
diff -u -r1.167 ThreadPThread.m3
--- ThreadPThread.m3    8 Nov 2009 23:09:21 -0000       1.167
+++ ThreadPThread.m3    8 Nov 2009 23:21:38 -0000
@@ -53,6 +53,8 @@
   Activation = UNTRACED REF RECORD
     mutex: pthread_mutex_t := NIL;

+    self: T; (* reference traced part *)
+
     (* a place to park while waiting *)
     cond: pthread_cond_t := NIL;

@@ -428,6 +430,7 @@
       pthread_cond_delete(cond);
       RTE.Raise(RTE.T.OutOfMemory);
     END;
+    act.self := t;
     act.mutex := mutex;
     act.cond := cond;
     RTHeapRep.RegisterFinalCleanup (t, CleanThread);
@@ -465,6 +468,16 @@
       self := slots [me.slot];
     WITH r = pthread_mutex_unlock_slots() DO <*ASSERT r=0*> END;

+    RTIO.PutAddr(me);
+    RTIO.PutText("\n");
+    RTIO.PutAddr(LOOPHOLE(self, ADDRESS));
+    RTIO.PutText("\n");
+    RTIO.PutAddr(LOOPHOLE(me.self, ADDRESS));
+    RTIO.Flush();
+
+    <*ASSERT me.self # NIL *>
+    <*ASSERT me.self = self *>
+
     (* Run the user-level code. *)
     IF perfOn THEN PerfRunning() END;
     self.result := self.closure.apply();

 


Doesn't work. Untraced memory can't contain traced pointers, because the traced part can get moved and the untraced thing won't get updated. Right? Using an integer is a "workaround".

 

Furthermore we need all this roundabout stuff because the GC can't see thread locals.

 

OK.

 - Jay

 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu; m3devel at elegosoft.com
Subject: ThreadBase/RunThread
Date: Sun, 8 Nov 2009 23:05:27 +0000



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/20091108/c98fcb5e/attachment-0002.html>