[M3devel] M3 programming problem : GC efficiency / per-thread storage areas?

[Mika Nystrom]

No, I didn't mean that it *necessarily* involves a context switch.
Obviously it doesn't, because the user-level threading doesn't
ever need to do a "kernel" context switch (but of course does its
own switching, however I don't see that it would need that to get 
or set a variable).

I just meant that looking at the (C) implementation of pthreads I
have (on FreeBSD), on that system, it does seem to, as the code in
question is marked as "kernel code".

In any case I think I have been able to solve my particular problem
by identifying a data structure that is inherently only accessed
from a single thread (in my program) and attaching my memory recycling
trickery to that particular structure.  I get very little memory
allocation/GC and no need for locks at all, which is precisely the
effect I was going for.

I am still a little bit concerned about the performance of CM3-generated
code but the main culprit appears to be TYPECASE/ISTYPE now, far
from garbage collectors and thread libraries.  I'll send an update
if I can find something egregiously inefficient.

    Mika

Jay writes:
>
>Right and wrong.
>
>Right Tony was referring to Upthread.getspecific. Or on Windows WinBase.TlsGet
>Value.
>Wrong that this necessarily incurs a switch to the supervisor/kernel, and perh
>aps wrong to call that at a "context switch". It depends on the operating syst
>em.
>
>I will explain.
>
>On Windows/x86, the FS register points to a partly documented per-thread data 
>structure.
>C and C++ exception handling use FS:0.
>Disassemble any code. You'll find it is used. Not by Modula-3 though.
>
>Disassemble TlsGetValue.
>
> cdb /z %windir%\system32\kernel32.dll  
>
>0:000> uf kernel32!TlsGetValue
>kernel32!TlsGetValue:
...