[M3devel] ThreadBase/RunThread

[Tony Hosking]

NO!  You cannot have traced T in untraced Activation.  The collector  
can't find the T that way.  What if T moves?

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

> (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/d4c4a799/attachment-0002.html>