From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 18:36:41 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D4A416A4CE for ; Mon, 29 Mar 2004 18:36:41 -0800 (PST) Received: from mail1.mail.iol.ie (mail1.mail.iol.ie [193.120.142.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8C5E43D2D for ; Mon, 29 Mar 2004 18:36:40 -0800 (PST) (envelope-from s_sourceforge@nedprod.com) Received: from dialup326.ts522.cwt.esat.net ([194.165.169.70] helo=kate) by mail1.mail.iol.ie with esmtp (Exim 3.36 #9) id 1B897G-0006yR-00 for freebsd-threads@freebsd.org; Tue, 30 Mar 2004 03:36:39 +0100 From: "Niall Douglas" To: freebsd-threads@freebsd.org Date: Tue, 30 Mar 2004 02:24:09 +0100 MIME-Version: 1.0 Message-ID: <4068DA49.24401.5BE9BE4@localhost> Priority: normal In-reply-to: <40688A09.9070709@he.iki.fi> References: <40688B80.18775.48ADA9C@localhost> X-PM-Encryptor: IDWPGP-PM32, 4 X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT Content-description: Mail message body Subject: Re: GDB 6.0 and FreeBSD threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 02:36:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29 Mar 2004 at 23:41, Petri Helenius wrote: > >Here's a thought - surely on a M:N threading implementation the > >kernel and user side library can automatically optimise which threads > > don't need to be system scope? They could do this by maintaining a > > > I would hate to see this happen. The added complexity and > unpredictability would make implementations harder because you would > have to account for an optimizer which tries to think what´s best for > the crappy application/programmer who does not know what he wants. As I grow older, I believe that programmers should tell the computer what to do rather than how to do it. To tune the dependencies between threads waiting on each other is extremely tough, so tough most programmers don't bother. A 1:1 scheduler is usually written with the process side dumb as to what's happening in the scheduler so the kernel doesn't know about an impending i/o block or wait condition until it's traversed into kernel space. Basically what I'm suggesting is a form of spin lock for i/o points and greater devolvement of i/o operations out of the kernel. In something like the hurd this is supposed to be the whole point, but then that project has taken an age. I think we're really early into multithreading technology. We're very far from the perfect scheduler which could make multithreaded systems considerably faster than previous ones - there are user-land threaded i/o systems which gave Apache a massive speedup. An M:N system is clearly the future and we'll make mistakes in our first few attempts. However we'll get there eventually. > Why not just run all threads SCOPE_PROCESS? Then the system will do > that for you. The pthreads implementations I've seen won't utilise more than one processor unless it's SCOPE_SYSTEM. The obviates the reason most people use threads, hence the success of the 1:1 model which is a very blunt axe. > The great advantage of process scope threads is the fact that you can > hand over a mutex without going trough a process switch. I have a hand written mutex which avoids the kernel completely except to sleep and wake the thread. This process could also avoid the kernel as it's really a process-internal issue and my spin count code avoids that completely on low-contention locks. However, a thread context switch within the same process map is far less costly than a process context switch, even if it must enter the kernel - if this weren't so, all those diehard Unix fans wouldn't be having to face up to the death of the process forking model. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQGjMOcEcvDLFGKbPEQKMKACfZIoDBT+br69MgbW+sfgz9HANr0MAoKvn yldlx8YuekW9J9u4Gv6E54zU =LDUT -----END PGP SIGNATURE-----