Date: Tue, 30 Mar 2004 10:54:30 +0800 From: David Xu <davidxu@freebsd.org> To: Niall Douglas <s_sourceforge@nedprod.com> Cc: freebsd-threads@freebsd.org Subject: Re: GDB 6.0 and FreeBSD threads Message-ID: <4068E166.8050200@freebsd.org> In-Reply-To: <4068DA49.24401.5BE9BE4@localhost> References: <40688B80.18775.48ADA9C@localhost> <4068DA49.24401.5BE9BE4@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
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" > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4068E166.8050200>