[M3devel] dynamic chose between user/kernel threads?

[Peter Eiserloh]

>> [Jay] Some programs "better" with user threads
>> [Tony] Is this still true for modern kernel thread systems?
>
>I really don't know.
>Olaf /kind of/ indicated so (just in saying that it'd be a nice option to have).
>
>> [Jay] small stacks for many threads vs. larger stacks for calls to "the system"
>> [Tony] In a systems programming language like Modula-3 shouldn't threads have a relationship to the system?


>> Is it a boolean or an enum?
>> Cygwin might conceivably get pthreads support (Cygwin has it, but 
>> Modula-3/Cygwin does not).
>> Therefore, is the choice among "posix" threads, "pthreads" and "NT" 
>> threads?
>> Or just user vs. kernel?
>
>I would argue for user vs. kernel.


Correct me if I am wrong, but don't user threads all run
in the same process, and therefore, can't make use of
multi-processors (ie, SMP machines).  Many people now even
have dual core machines, or even quad core, let alone 
motherboards with many processors on them.

At least with Linux, the old system thread library (I
forgot its name, it been a number of years) used user
level threads.  Then Linus invented the clone() system
call, which acted similarly to a fork(), but kept the
same virtual memory and file contexts.  This allowed
threads to act like processes, and migrate to other
processors of an SMP machine.

This is what the Linux implementation of the pthread
library currently uses, to take advantage of modern
machine architectures.  This is a kernel thread under
Linux.

This should be significant reason for prefering the pthread
threading library, and should probably be the default.

Default to "kernel" theads.  Allow "user" threads.  Don't
make it a binary choice.  If a port wants to make available
a third (or fourth) threading option they should be able
to do so.  Just don't expect many people to jump up and
down for joy.

If a platform does not support kernel threads, (eg, PalmOS)
uh ... (what we don't support it yet), then only support
user threads.  

If a port were to be built that ran on bare hardware (such
as the "SPIN" OS) they would have to implement their own
thread mechanism, and must not include any support for a
thread library which expects to be in user space with a
kernel providing OS support.

BTW: I think putting IF statements in all the threading
code looks ugly.  Couldn't you implement it as an OBJECT
ThreadMechanism, and derive the specific mechanisms:
   ThreadUserMechanism, 
   ThreadPThreadMechanism, 
   ThreadWinNTMechanism,
   ThreadDoItYourselfMechanism.

The startup code would choose which one to instantiate.
All thread and mutex calls would use that object to 
perform its action.


+--------------------------------------------------------+
| Peter P. Eiserloh                                      |
+--------------------------------------------------------+