Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Mar 2003 21:59:40 -0500 (EST)
From:      Jeff Roberson <>
Subject:   1:1 Threading implementation.
Message-ID:  <>

next in thread | raw e-mail | index | archive | help
I realize that many people have strong feelings on this topic.  I'm asking
everyone up front to try not to devolve this thread into a bikeshed.

Thanks to the foundation provided by Julian, David Xu, Mini, Dan Eischen,
and everyone else who has participated with KSE and libpthread development
Mini and I have developed a 1:1 threading implementation.  This code works
in parallel with KSE and does not break it in any way.  It actually helps
bring M:N threading closer by testing out shared bits.

I have successfully run mozilla 1.2.1 using this threading package.  It
still has some bugs and some incomplete corners but we're very close to
being able to commit this.  I'm going to post a link to the kernel portion
of this code at the end of this mail.  The library will come later.

What this means is that for every pthread in an application there is one
KSE and thread.  There is also only one ksegroup per proc in this model.
Since the kernel knows about all threads it handles all scheduling
decisions and all signal delivery.  I have followed the POSIX spec while
implementing the signal code.  I would really appreciate review from
anyone who is intimately familiar with signals and threads.  Included in
this is an implementation of sigwait(), sigtimedwait(), and sigwaitinfo().

The user land mutexes are supported by kernel code.  Uncontested acquires
and releases are done entirely in application space using atomic
instructions.  Once there is contention the library falls back to system
calls to handle the locks.  There are no per lock kernel resources
allocated.  There is a user space safe atomic cmpset function that has
been defined for x86 only at the moment.  New architectures require only
this function and the *context apis to run this threading package.  There
is no arch specific code in user space.

The condition variables and other blocking situations are handled with
sig*wait*() and a new signal, SIGTHR.  There are many reasons that we went
with a signal here.  If anyone cares to know them, you may ask.

There are only 4 system calls for threading. thr_create, thr_self,
thr_exit, and thr_kill.  The rest of the functionality is implemented in a
library that has been heavily hacked up from the original libc_r.

The reason we're doing this in parallel with the M:N effort is so that we
can have reasonable threading sooner.  As I stated before, this project is
complimentary to KSE and does not prohibit it from working.  I also think
that the performance will be better or comparable in the majority of real

The kernel bits are available at

I'd like to get the signal code commited asap.  It's the majority of the
patch and I often have to resolve conflicts.  There have been no
regressions in KSE or non threaded applications with this signal code.


To Unsubscribe: send mail to
with "unsubscribe freebsd-arch" in the body of the message

Want to link to this message? Use this URL: <>