sched_4BSD

[Steve Watt]

In <20050306101423.44745.qmail at web52702.mail.yahoo.com>,
  Kamal R. Prasad <kamalp at acm.org> wrote:
>--- Steve Watt <steve at Watt.COM> wrote:
[ snip ]
>> NPTL is a particular (less brain damaged than
>> LinuxThreads)
>> implementation of the POSIX thread standard.
>> 
>> Likewise, scheduler activations are a decent
>> implementation of
>
>doesn't that have a problem with M:N performance (M |=
>N)?

"Problem"?  Scheduler activations may be used to build M:N
systems, but that is not a requirement -- you can easily
build a 1:1 (all threads are system contention scope) system
with activations.

Admittedly, at this point in industry experience, most
threads experts will say that M:N threading usually isn't
worth the implementation headaches.  But there are definite
classes of problem, often having to do with certain styles
of user-interface design or a less-than-optimal object
system, where thousands of threads are a useful developer
convenience.  Very many processes with thousands of threads
in them will drag down a 1:1 system pretty rapidly.

>> Julian> so how does that differ from what we have
>> ... a
>> Julian> native pthreads library?
>> 
>> Kamal>I just said if it was conformant with NPTL,
>> thread and
>> Kamal>process scheduling would co-exist.
>> 
>> Uh, as far as I understand, in NPTL, each thread
>> gets a scheduler
>> slot, and it is my understanding that there is
>> nothing to protect
>> against the issue that Julian is asking about (1000
>> threads of a
>> single process *do* get 1000 times the time slices).
>> 
>
>(AFAIK) Referring to the POSIX std (and not NPTL) -if
>threads were defined within process scope and not
>system scope -the scheduling attributes of the process
>will apply.

Yes, and a system that has both system scope and process
scope is usually called an M:N system.

I will grant that it is possible for the kernel to be aware
of all of the threads in the system (i.e. a 1:1 model) but
handle contention scope correctly.  I don't think anyone
has built such a system, but would be happy to be proven
wrong -- it'd be a useful advancement of the art.  One
challenge is accounting for time on threads that don't do
much work when awakened before going back to sleep -- if
there are 1000 process-scope threads, and all of them run
for half a millisecond and block, in the aggregate you
need to charge the process the entire 500mS, or the
timesharing characteristics won't come out right.  It's
somewhat challenging to do that charging cheaply.

-- 
Steve Watt KD6GGD  PP-ASEL-IA          ICBM: 121W 56' 57.8" / 37N 20' 14.9"
 Internet: steve @ Watt.COM                         Whois: SW32
   Free time?  There's no such thing.  It just comes in varying prices...