From owner-freebsd-threads@FreeBSD.ORG Mon Mar 29 18:53:37 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 67B9916A4CE for ; Mon, 29 Mar 2004 18:53:37 -0800 (PST) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id C58A743D3F for ; Mon, 29 Mar 2004 18:53:30 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HNTCCAPG; Tue, 30 Mar 2004 10:54:05 +0800 Message-ID: <4068E166.8050200@freebsd.org> Date: Tue, 30 Mar 2004 10:54:30 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Niall Douglas References: <40688B80.18775.48ADA9C@localhost> <4068DA49.24401.5BE9BE4@localhost> In-Reply-To: <4068DA49.24401.5BE9BE4@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-threads@freebsd.org 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:53:37 -0000 Niall Douglas wrote: >-----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. > This is ideal case, in real world, a thread switch could cause a thread from other process be scheduled, this would cause CR3 on i386 to be reloaded for a new process, even when you are handing a pthread mutex off to a thread in same process. >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----- >_______________________________________________ >freebsd-threads@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-threads >To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > > > >