GDB 6.0 and FreeBSD threads

Niall Douglas s_sourceforge at
Mon Mar 29 11:48:12 PST 2004

Hash: SHA1

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 and representative?

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.


Version: idw's PGP-Frontend / 9-2003 + PGP 8.0.2


More information about the freebsd-threads mailing list