[M3devel] [M3commit] how to switch userthreads on/off

[Tony Hosking]

There is no lock in the fast path for traced allocation.  GC has some  
locking that I am working on improving/eliminating.  Watch this space.

On 29 Apr 2009, at 16:22, Mika Nystrom wrote:

> Jay writes:
> ...
>>
>> Maybe just leave it as an option in m3core's m3makefile and people  
>> can twiddle it if they want and rebuild the entire system like it  
>> is today?
>> That is a bit onerous, but maybe it's all userthreads deserve?
>> ?
>>
>>
>> Anyone who actually wanted to switch back and forth (Mika) would  
>> just have two installs and two source trees?
>>
>>
>> - Jay
>
> I just want to clarify.  I'm not really that interested in switching
> back and forth.  I'm just a little disturbed by the sometimes huge
> performance loss due to the introduction of kernel threads.  I knew
> that this would happen in certain highly multithreaded applications,
> but I'm surprised it happens in a more or less single-threaded
> application.
>
> I think I've just been spoiled by 10 years of using SRCM3 and PM3
> for FreeBSD w/o kernel threads in the sense that I've learned that
> using LOCK has essentially no cost.  On a shared-memory  
> multiprocessor,
> I really don't expect that to remain the case... physics won't allow
> it.  So now I just have to go through my code and find all the places
> where I lock too much and remove them.
>
> But the memory allocator and garbage collector do it too, no?
>
> I also think that this idea of being able to use either is great.
> Mainly single-threaded programs should definitely not use kernel
> threads!
>
> As for reaching the "thread locals", there is one slightly crazy
> idea that one could borrow from Sussman and Steele: add another
> implicit argument to every Modula-3 routine.  In that argument,
> pass a pointer to the thread locals.  For EXTERNAL calls (in or
> out), make it NIL (somehow, maybe involving pragmas), and in that
> case (only), use the pthreads routines to access the thread locals.
> Ok so it sounds kind of nuts, but with this approach you could avoid
> locking or even calling into the pthreads libs almost entirely for
> a single-threaded program.  You could even have a thread-local
> memory allocator that would only lock when it needs to request
> memory from the "global allocator"...   in fact there are lots of
> things you can do with this sort of thing.  Dynamically scoped
> variables in Scheme (a la MacLisp?) is what they originally proposed
> it for but then they suggested all kinds of tricks related to
> continuations with it.
>
>    Mika