From owner-freebsd-hackers Mon Aug 12 03:45:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA13173 for hackers-outgoing; Mon, 12 Aug 1996 03:45:52 -0700 (PDT) Received: from proxy.siemens.at (proxy.siemens.at [192.138.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA13162 for ; Mon, 12 Aug 1996 03:45:25 -0700 (PDT) Received: from sol1.gud.siemens.co.at (sol-f.gud.siemens-austria) by proxy.siemens.at with SMTP id AA08297 (5.67a/IDA-1.5 for ); Mon, 12 Aug 1996 12:44:28 +0200 Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0upuU0-00025jC; Mon, 12 Aug 96 12:44 MET DST Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA063596403; Mon, 12 Aug 1996 12:40:03 +0200 From: "Hr.Ladavac" Message-Id: <199608121040.AA063596403@ws2301.gud.siemens.co.at> Subject: Re: FreeBSD vs. NT Stability To: igor@jabber.paco.odessa.ua (Igor Khasilev) Date: Mon, 12 Aug 1996 12:40:03 +0200 (MESZ) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199608120912.MAA21871@jabber.paco.odessa.ua> from "Igor Khasilev" at Aug 12, 96 12:12:33 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk E-mail message from Igor Khasilev contained: > > > So my question is: how does NT behave when it has to schedule between a > > large number of processes each with its own process context, VM, page tables > > etc? Conversely how does the unix program behave when linked with -lpthreads > > and with `fork()' replaced with `pthread_create()'? > > One bad thing with user level threads (actualy pthreads that I used): > sheduler which runs on user lever ALWAYS consume processor time (even wnen Only when *really* poorly implemented. Otherwise it waits in select(2) to be awaken by the incoming traffic or that the timeout fires (condition timed wait, for instance.) When all threads are blocked, no VTALRM's should be scheduled (I don't know if CAP's pthread implements the last optimization.) > all threads sleeps), and permanenly keep part of code in memory. If it is > true (maybe I misunderstand something), then pthreads is bad solution for > heavy loaded systems. See above. It *is* true, as long as there are threads capable of running (i.e. not blocked), but this is the outcome one desires: runnable threads run. As soon as all threads are blocked, the scheduler goes to sleep, so to say, and is eligible for LRU paging. Naturally, for really heavy bursty I/O, kernel based threads would be better, but there are very many instances of potential threading where kernel based threads are just too heavyweight. The VIPER project for Linux produced some interesting documentation on the matter and contains pointers for further reading, if anyone is interested (it never came to bloom, AFAIK, for political reasons) /Marino > > Igor >