GDB 6.0 and FreeBSD threads

Niall Douglas s_sourceforge at nedprod.com
Mon Mar 29 18:36:41 PST 2004


-----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-----


More information about the freebsd-threads mailing list