Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!hellgate.utah.edu!dog.ee.lbl.gov!ucbvax!mtxinu!sybase!ohday!tim From: tim@ohday.sybase.com (Tim Wood) Newsgroups: comp.os.mach Subject: Re: Threads, Definition of Message-ID: <12362@sybase.sybase.com> Date: 16 Feb 91 00:15:58 GMT References: <4964@umbc3.UMBC.EDU> <1476@pdxgate.UUCP> <21892@oolong.la.locus.com> Sender: news@Sybase.COM Organization: Sybase, Inc. Lines: 29 In article jgmorris@CS.CMU.EDU (Greg Morrisett) writes: > >There is an additional advantage to letting your OS know about your >threads: If one thread blocks for I/O, your whole task doesn't have >to be preempted. Some threads packages that are entirely in the >runtime get around explicit I/O preemption by doing a non-blocking call >(e.g. select) before doing the blocking call. You can also use an async I/O facility if it's available. Most production operating systems have it (and UNIX systems seem to just be getting it.) >But this sort of trick >isn't possible on a page fault. Note that this advantage applies >to uni-processors as well as MPs. Async I/O doesn't help you for a page fault either. And it's harder to do SMP with user-mode threads (basically you need LWP on top of HWP). But async I/O plus user-mode threads plus enough memory to hold your whole program should be the fastest combination, since the program (bunch of threads) should never block except voluntarily and context switches don't require a system call. This is (very tersely) how Sybase's SMP DBMS is built. -TW --- Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 WORK:tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim PLAY:axolotl!tim@toad.com {sun,uunet}!hoptoad!axolotl!tim Dis claim er dat claim, what's da difference? I'm da one doin da talkin' hea.