[M3devel] [M3commit] CVS Update: cm3

[Jay]

I'm aware of systems without threads, e.g. MS-DOS
or apparently many of the systems Modula-3 first ran on.
(Really? pthreads wasn't very available back then?)
 
 
The case of many threads, um..
You don't run out of address space on the stacks?
I guess the Modula-3 stuff honors requests for very small stacks?
  (need to fix that it leaks a pthread_attr here..)
Not a problem on 64bit systems.
 
 
The large number of threads doesn't bog down scheduling?
 
 
Is it hundreds/thousands of threads alive at the same time, or serially?
Serially, no big deal.
 
 
Modifiable, sure. The more you implement "yourself", the
more you can change. You can hope for folks to build in some
"configurability" and "tunability", but nothing beats
the ability to change or replace the thing arbitrarily.
 
 
Maybe having hundreds/thousands is "wrong"?
I have repeatedly seen guidance against creating "many" threads.
  Better to have a "thread pool", and/or use "completion ports" (aka select?).
Maybe you should have just a few threads, and then decide for yourself
what each should run?
You know, isn't the guidance to have roughly one thread per processor?
You aren't going to scale beyond that..unless you dedicate a thread
per slow i/o, which is wasteful.
 
 
You know there is this whole thing where..too many cooks spoil the broth.
Having multiple schedulers on the system means they won't do an ideal job.
It is best to have one scheduler, that "knows everything" -- knows about
all the threads and what they are waiting for.
 
 
The cost of threads..is both low and high.
 
 
 - Jay

----------------------------------------
> To: jay.krell at cornell.edu
> Date: Mon, 29 Dec 2008 01:23:17 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> Jay writes:
>>
> ...
>>
>>I'm still not much of a believer in user threads.
>>Essentially I have always had kernel threads, with a processor-portable
>>interface, and one machine-wide scheduler..seems good..
>>
> ...
>
> Except that on some machines, some operating systems, Modula-3's
> user threads are much more efficient (and if not, far more easily
> modifiable) than the provided kernel threads when you perform certain
> types of operations in certain situations. I often write programs
> with many (hundreds, thousands) of active threads and run into these
> sorts of problems frequently.
>
> You could argue that it should not be so... that every OS should
> provide kernel threads that are better than Modula-3's own user
> threads under all conceivable workloads, but what good does that
> do? Seems better to have a way of avoiding that can of worms by
> being able to control one's own implementation.
>
> Another reason that occurred to me when reading some very old
> M3 documentation is that there do occasionally exist systems
> that don't have a real operating system. There may also be
> other deficient systems that don't have pthreads. With an existing
> user-level threading library you can easily support such systems.
> (M3 has supported such systems in the past...)
>
> Mika