<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
> Terminology wrong, but your point is correct.<BR>
<BR>
A "process" is an "address space" and isolation boundary for security.<BR>
A thread is a unit of scheduling, a stack and register context.<BR>
<BR>
"Straightforward" user threads indeed, you would only ever run one at a time,<BR>
per process, even on a multi threaded systems.<BR>
<BR>
People speak of <BR>
N:M <BR>
1:1 <BR>
or N:1 <BR>
<BR>
One number is number of user threads.<BR>
The other is kernel threads.<BR>
You can have a hybrid where some number of user threads are scheduled<BR>
on some smaller number of kernel threads.<BR>
<BR>
You can have one to one.<BR>
<BR>
You can have one kernel thread (e.g. on a system without kernel threads--<BR>
just processes) that you use to run multiple user threads.<BR>
<BR>
Historically N:1 was the only option.<BR>
Then some people moved to N:M. Such as older releases of Solaris.<BR>
These days almost everything is 1:1.<BR>
However some people still don't think this is clearly and always best.<BR>
And on rare occasion, perhaps it is not.<BR>
<BR>
N:M is an interesting hybrid, it gives user threads a chance to<BR>
scale on a multiprocessor. But it is probably the most difficult<BR>
to implement. If you read near the beginning of the 2nd edition<BR>
of "Solaris Internals" they talk about some of this, and how Solaris 10<BR>
(9?) improved things by making it all "1:1".<BR>
<BR>
I consider user threads extremely uninteresting but<BR>
folks here are vocally interested in them.<BR>
<BR>
And right there are systems without kernel threads.<BR>
Like, I've been thinking of making a I386_MSDOS_DJGPP or such release.<BR>
It appears to have sufficient support for the user threads -- alarm().<BR>
<BR>
> IF looks ugly. Couldn't you implement it as an OBJECT <BR> <BR>
I said function pointers at one point. Same thing. <BR>
<BR>
If it was IF, it'd be an extra layer outside all of the "real" code<BR>
and so wouldn't be ugly at all. But maybe slower.<BR>
<BR>
<BR>
Something I've been meaning to ask.<BR>
The old Linux library was "LinuxThreads".<BR>
"NPTL" is the Native PThread Library.<BR>
Modula-3 only seemed to switch to pthreads with NPTL widely available.<BR>
But I assume the pthreads interface was implemented over LinuxThreads?<BR>
Couldn't Modula-3 have used that, earlier?<BR>
That is, couldn't Modula-3 using pthreads claim to work to older versions?<BR>There's a comment in thread/m3makefile that suggests NPTL is required.<BR>
I guess it is moot. NPTL is here and nobody probably runs the older stuff??<BR>
(I ran Modula-3/LINUXELF briefly on 1.2. Imho binary compatibility mandates<BR>
that it should still work... certainly I continue to use Windows software<BR>
from the same time period every day.)<BR>
<BR>
- Jay<BR><BR><BR>> Date: Mon, 12 Jan 2009 23:31:27 -0800<BR>> From: eiserlohpp@yahoo.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: [M3devel] dynamic chose between user/kernel threads?<BR>> <BR>> >> [Jay] Some programs "better" with user threads<BR>> >> [Tony] Is this still true for modern kernel thread systems?<BR>> ><BR>> >I really don't know.<BR>> >Olaf /kind of/ indicated so (just in saying that it'd be a nice option to have).<BR>> ><BR>> >> [Jay] small stacks for many threads vs. larger stacks for calls to "the system"<BR>> >> [Tony] In a systems programming language like Modula-3 shouldn't threads have a relationship to the system?<BR>> <BR>> <BR>> >> Is it a boolean or an enum?<BR>> >> Cygwin might conceivably get pthreads support (Cygwin has it, but <BR>> >> Modula-3/Cygwin does not).<BR>> >> Therefore, is the choice among "posix" threads, "pthreads" and "NT" <BR>> >> threads?<BR>> >> Or just user vs. kernel?<BR>> ><BR>> >I would argue for user vs. kernel.<BR>> <BR>> <BR>> Correct me if I am wrong, but don't user threads all run<BR>> in the same process, and therefore, can't make use of<BR>> multi-processors (ie, SMP machines). Many people now even<BR>> have dual core machines, or even quad core, let alone <BR>> motherboards with many processors on them.<BR>> <BR>> At least with Linux, the old system thread library (I<BR>> forgot its name, it been a number of years) used user<BR>> level threads. Then Linus invented the clone() system<BR>> call, which acted similarly to a fork(), but kept the<BR>> same virtual memory and file contexts. This allowed<BR>> threads to act like processes, and migrate to other<BR>> processors of an SMP machine.<BR>> <BR>> This is what the Linux implementation of the pthread<BR>> library currently uses, to take advantage of modern<BR>> machine architectures. This is a kernel thread under<BR>> Linux.<BR>> <BR>> This should be significant reason for prefering the pthread<BR>> threading library, and should probably be the default.<BR>> <BR>> Default to "kernel" theads. Allow "user" threads. Don't<BR>> make it a binary choice. If a port wants to make available<BR>> a third (or fourth) threading option they should be able<BR>> to do so. Just don't expect many people to jump up and<BR>> down for joy.<BR>> <BR>> If a platform does not support kernel threads, (eg, PalmOS)<BR>> uh ... (what we don't support it yet), then only support<BR>> user threads. <BR>> <BR>> If a port were to be built that ran on bare hardware (such<BR>> as the "SPIN" OS) they would have to implement their own<BR>> thread mechanism, and must not include any support for a<BR>> thread library which expects to be in user space with a<BR>> kernel providing OS support.<BR>> <BR>> BTW: I think putting IF statements in all the threading<BR>> code looks ugly. Couldn't you implement it as an OBJECT<BR>> ThreadMechanism, and derive the specific mechanisms:<BR>> ThreadUserMechanism, <BR>> ThreadPThreadMechanism, <BR>> ThreadWinNTMechanism,<BR>> ThreadDoItYourselfMechanism.<BR>> <BR>> The startup code would choose which one to instantiate.<BR>> All thread and mutex calls would use that object to <BR>> perform its action.<BR>> <BR>> <BR>> +--------------------------------------------------------+<BR>> | Peter P. Eiserloh |<BR>> +--------------------------------------------------------+<BR>> <BR>> <BR>> <BR><BR></body>
</html>