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

[Mika Nystrom]

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