[M3devel] dynamic chose between user/kernel threads?

Thu Jan 8 14:38:25 CET 2009

As I noted earlier, I think that a link-time choice between
(M3) user and system (kernel/p) threads would be completely
satisfactory. Default could be pthreads/system threads, and
cm3 -uthreads or cm3 -m3threads could substitute the old but
efficient M3 implementation (with proper getcontext/makecontext
for all target platforms ;-).

Olaf

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> On 8 Jan 2009, at 14:10, Jay wrote:
>
>> Olaf understood the point (I think). :)
>>
>> Some programs, people say, and I believe, run "better" (faster,    
>> without running out of address space) with user threads instead of   
>>  kernel threads.
>
> Is this still true for modern kernel thread systems?
>
>> On systems that have both.
>> A good example might be a program that needs lots of threads and    
>> therefore small stacks, and the kernel threads, due to code below    
>> the Modula-3 runtime, might force fairly large stacks. (Such a    
>> program might have to adjust thread size differently for different   
>>  threads, and only call into the underlying system on threads with   
>>  larger stacks.)
>
> In a systems programming language like Modula-3 shouldn't threads have
> a relationship to the system?
>
>> It might be nice for such programs to be able to mandate or request  
>>   (two slightly different things) that the user thread library be   
>> used  by them, even if the platform's default is to use kernel   
>> threads.
>
> This will need to be a link-time distinction.  I would hate to have
> both kernel and user thread code live in the same compiled run-time
> system.
>
>> The only minor detail then is, how to express the request, and the   
>>  precise meaning.
>> It is a request or a mandate?
>
> I see no problem with factoring out the threads subsystem as a
> separate library and linking accordingly.
>
>> As well, if the issue is address space, sholud there a "built in"    
>> way to only make the request on 32bit platforms, or should uses    
>> manually say if equal (WORD_SIZE, "32BITS")?
>>
>> 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.
>
>> I think the "important" part here is easy to implement.
>> But again..
>
> And managing the state-space explosion that multiple choices might
> entail.  I would like to avoid that.
>
>> The easier straightforward implementation always links both pieces   
>>  of code in and makes a choice early in startup as to which to use,  
>>   either setting a boolean, or an enum, or a pointer to a record of  
>>   function pointers. This means that people that don't care to ever  
>>   use user threads pay a small price, in code bloat and probably in  
>> a   few extra instructions per certain functions. This is probably  
>> ok.
>
> I am not so sure, since it would entail some fairly low-level and
> expensive decisions that would best instead be done at link-time.
>
>> However if that was not ok, the choice could be made at link time    
>> and only be supported for standalone programs.
>
> Actually, for non-standalone (dynamically-linked) code we could make
> the choice at dynamic load time using the OS's support for dynamic
> library choice.
>
> I note that Solaris (but not Solaris Modula-3) currently lets
> dynamically linked C programs choose among 3 different threads
> implementations dynamically.
>
>>
>>
>> - Jay
>>
>>
>>
>>
>> CC: wagner at elegosoft.com; m3devel at elegosoft.com
>> From: hosking at cs.purdue.edu
>> To: jay.krell at cornell.edu
>> Subject: Re: [M3devel] dynamic chose between user/kernel threads?
>> Date: Thu, 8 Jan 2009 13:51:15 +1100
>>
>>
>> Jay, perhaps you can provide some context and motivation for your    
>> proposals.  I am unable to evaluate your proposals in the form of a  
>>   simple laundry-list.
>>
>> On 8 Jan 2009, at 01:34, Jay wrote:
>>
>> I looked into this a bit..and I think it's actually pretty easy.
>> It hardly churns the code even.
>>
>>
>> I have other things I want to do first.
>>
>>
>> In the meantime, specify the directive?
>> There are actually a large number of subtle options.
>>
>>
>> Can I ask for any of n libraries -- NT, pthreads, user threads?
>> setjmp vs. context? Or is it just a boolean, user vs. kernel?
>>
>>
>> Is the option to "favor" or "require" a certain library?
>>
>>
>> Can I set it on libraries or only programs?
>> What if the requests clash?
>>
>>
>> Is it "Favor" or "Require"?
>> Is it a function call or setting a global variable?
>> I favor function call, but TARGET, WORD_SIZE, BUILD_DIR establish    
>> the other precedent,
>> and either can work.
>>
>> Is it flags in the moduleinfo like incgc, gengc, or separate data that
>> there is just one of in RTLinker? Probably separate data, unless it  
>>   is allowed in libraries.
>>
>>
>> What are the names of the libraries?
>> "posix" and "pthreads"  ?
>>  "user" and "kernel" ?
>>  "true" and "false" (or vice versa) ?
>>
>>
>> Should NT implement user threads, using fibers?
>>
>>
>> Presumably it works with both standalone and shared/dynamic programs.
>> Presumably it is ok to always bloat up m3core.dll with both libraries.
>> Presumably it is ok to have everyone pay a teeny tiny perf.
>>  That is, there is a microscopic dispatching layer, that everyone
>>  ends up going through, not chosing to link in one library or the  other.
>>
>>
>> And as part of this, whenever it happens, can we bump up the minimum
>> bootstrap to a version that includes  SchedulerPosix.DoesWaitPidYield()?
>> Or does it become VAR Scheduler.UsingKerneThreads?
>> (no, it should be a function; but naming matter remains).
>>
>>
>> (ie. as I said, the decision currently is baked into m3core.dll, but
>> now it is also baked into sysutils.dll, but these should change  together;
>> m3core.dll should manage the knowledge).
>>
>>
>> - Jay
>>
>>
>>> Date: Sat, 3 Jan 2009 01:12:27 +0100
>>> From: wagner at elegosoft.com
>>> To: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] dynamic chose between user/kernel threads?
>>>
>>> An option to cm3 or a quake directive to use in the m3makefiles
>>> would suffice in my opinion (and be a great improvement).
>>>
>>> Olaf
>>>
>>> Quoting Jay <jay.krell at cornell.edu>:
>>>
>>> >
>>> > Should the user/kernel thread chose be available:
>>> >
>>> >
>>> > On the command line to a Modula-3 executable (or even an  executable
>>> > where main is in another language, but which static or dynamic
>>> > Modula-3 libs are used)?
>>> >
>>> >
>>> > Via a quake directive when building programs?
>>> >
>>> >
>>> > You know, imagine you have a bunch of Modula-3 programs and some  but
>>> > not all use a very large number of threads and benefit from
>>> > userthreads.
>>> >
>>> >
>>> > Currently the chose is locked into m3core when it is built.
>>> >
>>> >
>>> > - Jay
>>>
>>>
>>> --
>>> Olaf
>>
>>

-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194