GDB 6.0 and FreeBSD threads
s_sourceforge at nedprod.com
Mon Mar 29 11:48:12 PST 2004
-----BEGIN PGP SIGNED MESSAGE-----
On 28 Mar 2004 at 23:41, Julian Elischer wrote:
> On this topic, There are 3 separate compatible threads libraries
> Libc_r is only SCOPE_PROCESS, libpthreads implements SCOPE_PROCESS and
> SCOPE_SYSTEM, and libthr is only SCOPE_SYSTEM. Do you run ALL threads
> as scope system, or only some? We don't recommend COPE_SYSTEM unless
> it's really needed (for example to make some threads run at
> higher/lower priorities) as they are less efficient. Benchmark your
> app with both types. (I think Linux is only SCOPE_SYSTEM).
The project also runs on Windows so up till now it's been assumed
SCOPE_SYSTEM. That's too much for some of the threads so I'm very
open to having some of them run as in-process threads. I had this in
mind when designing the thread class, it's an easy extension.
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
sleep & i/o history for each thread, noting when which threads run
concurrently, which i/o dependencies exist between threads and from
that dynamically rescope the thread plus perform dynamic priority
boosting to minimise sleeps. Indeed, if the kernel scheduler felt it
was being overtaxed, more threads could be moved in-process.
To me there is little point investing in all the complexity of a M:N
implementation if you don't implement such optimisation features -
otherwise the substantial amounts of extra code cause things to run
slower due to sheer binary size. Of course this subtly breaks POSIX
compliance as you ignore what the application asks for - it also
requires an inprocess scheduler which works identically to the kernel
one, and currently libc_r doesn't do that.
> > BTW on my FreeBSD v5.2.1 the library is called libkse, not
> > libpthread which doesn't exist.
> That's the problem with the fact that this field moving so quickly.
> You should probably upgrade to -current so that you can debug these
> threads. and get reeady for yur app to run on 5.3.
I had thought, perhaps foolishly, that since MacOS X has good
threading support and it comes from FreeBSD then therefore FreeBSD
must have mature threading support.
You seem to have the functionality okay, just none of the tools quite
yet. Writing threaded code is hard without a debugger! And for some
strange reason, my sockets class hangs on FreeBSD when it works fine
everywhere else. As all the blocking i/o in my project is done by
threads, I have given up trying to debug it.
> directly to david.. it's still in prerelease.
> Also, you MUST be running TODAY'S -current so you'll need to upgrade.
> Sorry but it's an area of active development.
The roadmap says v5.3 beta will be out 1st March. I take it this has
What precisely will be changing in v5.3? Is
Lastly, does the new scheduler give better performance on
uniprocessor machines over the old one? I actually compiled it out
for my kernel assuming a SMP kernel is slower on uniprocessor.
-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 18.104.22.168 / 9-2003 + PGP 8.0.2
-----END PGP SIGNATURE-----
More information about the freebsd-threads