[M3devel] dynamic chose between user/kernel threads?
Tony Hosking
hosking at cs.purdue.edu
Fri Jan 9 01:01:26 CET 2009
I err on the side of simplicity, until there is an obvious need for
adding complexity. In this case, I concur with Olaf that the most we
would need is a simple link-time switch.
Antony Hosking | Associate Professor | Computer Science | Purdue
University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484
On 9 Jan 2009, at 00:38, Olaf Wagner wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090109/23d20fe3/attachment-0002.html>
More information about the M3devel
mailing list