Re: Tasking performance between Ada83 and Ada95

[kilgallen@eisner.decus.org (Larry Kilgallen)]

n article <5oq70f$4f@mulga.cs.mu.OZ.AU>, fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> 
>>Geert Bosch <geert@gonzo.sun3.iaf.nl> writes:
>>
>>> IMO the best solution would be to start X system level threads and
>>> implement a user-level threads package on top of it.
>>
>>That is the method used by Alpha VMS.  The kernel thread primitives
>>in fact are not documented for public consumption.  The documented
>>interface is the DECthreads library (which has a couple different
>>APIs matching varying styles and standards).  DECthreads creates the
>>user-mode lightweight threads which then get scheduled onto some
>>number of kernel threads (typically numbering on the order of the
>>number of CPUs).
> 
> What happens with blocking I/O?  Does DECthreads implement blocking
> I/O operations using asynchronous kernel I/O operations, so that it 
> will avoid blocking a whole kernel thread when all that really needs
> to be blocked is a user thread?

Well DECthreads does not actually implement the I/O operations itself,
or else they might be tying the DECthreads I/O support to a particular
language, and they might make the wrong choice :-)

DECthreads has its hooks into the System Service Dispatcher of the
base OS so that DECthreads will get an "upcall" invocation when IO
is about to block.  DECthreads then has the opportunity to switch
which lightweight thread is active on a given kernel thread before
the kernel thread "really" stalls.  If DECthreads is smart enough to
choose a lightweight thread which is not blocked :-), there is no stall.

That "upcall" mechanism can even work when there is only a single
kernel thread.  In the future it might be enabled also on VAX,
where kernel threads are not available (moral equivalent of
having a single kernel thread), although that does not affect
DEC Ada directly, since on VAX DEC Ada does not use DECthreads.
On VAX, DEC Ada Pragma TIME_SLICE does a less timely job of
preventing stalled threads from blocking the whole process
by using a timer AST (timeliness under programmer control
for a price (overhead)).

Both the AST mechanism and the upcall mechanism only work when the
wait is in user mode, since that is the only case the state of the
process is well-known.  Most System Service waits are in user mode
these days, although those who used VMS V1 may remember programs
from which one could not escape via CTRL/Y or CTRL/C, often due
to System Services which waited in inner modes.

> If not, then choosing the right number of kernel threads may be a bit
> tricky -- you want one for each CPU, to get multiprocessing, but
> you also need one for every user-level thread that might get blocked
> on I/O, so that you background compute threads don't get paused
> when your foreground threads are doing blocking I/O.

But such an implementation would still get a marketing "checkoff"
for supporting "kernel threads" :-)

Larry Kilgallen