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