[M3devel] dynamic chose between user/kernel threads?

[Jay]

  > Terminology wrong, but your point is correct.
 
A "process" is an "address space" and isolation boundary for security.
A thread is a unit of scheduling, a stack and register context.
 
"Straightforward" user threads indeed, you would only ever run one at a time,
per process, even on a multi threaded systems.
 
People speak of 
  N:M  
  1:1  
  or N:1  
 
One number is number of user threads.
The other is kernel threads.
You can have a hybrid where some number of user threads are scheduled
on some smaller number of kernel threads.
 
You can have one to one.
 
You can have one kernel thread (e.g. on a system without kernel threads--
just processes) that you use to run multiple user threads.
 
Historically N:1 was the only option.
Then some people moved to N:M. Such as older releases of Solaris.
These days almost everything is 1:1.
However some people still don't think this is clearly and always best.
And on rare occasion, perhaps it is not.
 
N:M is an interesting hybrid, it gives user threads a chance to
scale on a multiprocessor. But it is probably the most difficult
to implement. If you read near the beginning of the 2nd edition
of "Solaris Internals" they talk about some of this, and how Solaris 10
(9?) improved things by making it all "1:1".
 
I consider user threads extremely uninteresting but
folks here are vocally interested in them.
 
And right there are systems without kernel threads.
Like, I've been thinking of making a I386_MSDOS_DJGPP or such release.
It appears to have sufficient support for the user threads -- alarm().
 
 > IF looks ugly. Couldn't you implement it as an OBJECT  
 I said function pointers at one point. Same thing. 
 
 If it was IF, it'd be an extra layer outside all of the "real" code
 and so wouldn't be ugly at all. But maybe slower.
 
 
Something I've been meaning to ask.
The old Linux library was "LinuxThreads".
"NPTL" is the Native PThread Library.
Modula-3 only seemed to switch to pthreads with NPTL widely available.
But I assume the pthreads interface was implemented over LinuxThreads?
Couldn't Modula-3 have used that, earlier?
That is, couldn't Modula-3 using pthreads claim to work to older versions?There's a comment in thread/m3makefile that suggests NPTL is required.
I guess it is moot. NPTL is here and nobody probably runs the older stuff??
(I ran Modula-3/LINUXELF briefly on 1.2. Imho binary compatibility mandates
that it should still work... certainly I continue to use Windows software
from the same time period every day.)
 
 - Jay> Date: Mon, 12 Jan 2009 23:31:27 -0800> From: eiserlohpp at yahoo.com> To: m3devel at elegosoft.com> Subject: [M3devel] dynamic chose between user/kernel threads?> > >> [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 |> +--------------------------------------------------------+> > > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090113/395a1d40/attachment-0002.html>