GDB 6.0 and FreeBSD threads

Daniel Eischen eischen at vigrid.com
Mon Mar 29 22:25:36 PST 2004


On Tue, 30 Mar 2004, Niall Douglas wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 29 Mar 2004 at 22:38, Daniel Eischen wrote:
> 
> > > > 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.
> > 
> > That's untrue for libpthread.  It creates automatically creates one
> > KSE for each CPU.  You can increase the number of CPUs by setting
> > sysctls kern.threads.debug=1 and raising kern.threads.virtual_cpu. It
> > also respects pthread_setconcurrency, but you're limited to
> > kern.threads.virtual_cpu.  Yes, all process scope threads run in these
> > KSES.
> 
> My apologies if this is a question already answered many times 
> previously - what's then the difference between specifying 
> SCOPE_SYSTEM and SCOPE_PROCESS on libpthread? Is it basically whether 
> the thread competes with all threads or just with threads within its 
> process for that process' time slice?

It is exactly what POSIX says it should be.  All system scope
threads in the system compete against each for CPU time.  For
process scope threads, they use the process quantum (perhaps
multiplied by NCPU).

System scope threads get their own quantum and are inherintly
unfair in that they give their process more CPU time.

-- 
Dan Eischen



More information about the freebsd-threads mailing list