From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a5681531ca1cf09e X-Google-Attributes: gid103376,public From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: Tasking performance between Ada83 and Ada95 Date: 1997/06/25 Message-ID: <1997Jun25.075001.1@eisner>#1/1 X-Deja-AN: 252453845 X-Nntp-Posting-Host: eisner.decus.org References: <1997Jun6.115223.7384@relay.nswc.navy.mil> <7h6UFCAdNsmzEwg3@walsh.demon.co.uk> <5oir0v$mgu$1@gonzo.sun3.iaf.nl> <1997Jun23.101735.1@eisner> <5oq70f$4f@mulga.cs.mu.OZ.AU> X-Nntp-Posting-User: KILGALLEN X-Trace: 867239409/17952 Organization: LJK Software Newsgroups: comp.lang.ada Date: 1997-06-25T00:00:00+00:00 List-Id: 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 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