[M3devel] dynamic chose between user/kernel threads?

[Jay]

I think you didn't realize some of what I was lumping into "link time".
 
It could mean "constructing main to pass a parameter to RTLinker".
Or setting a flag in the Main module (like how gengc/incgc flags are set
in all modules, but this is a more difficult and likely wasteful change,
no need to burn a bit in all modules, just the main module).
 
 
I still think function pointers would suffice, costing zero or one instruction per function call..
But I haven't tried it yet.
 
 
Systems with "build variants" tend to get "explosive" -- combinatorial explosions of "configurations".
Boost is good (bad) example of this.
 
 - Jay> Date: Thu, 8 Jan 2009 14:38:25 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] dynamic chose between user/kernel threads?> > 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/20090108/e4c8b563/attachment-0002.html>