threads/118910: Multithreading problem

John Baldwin jhb at
Fri Dec 21 10:53:22 PST 2007

On Friday 21 December 2007 03:16:15 am Daniel Eischen wrote:
> On Fri, 21 Dec 2007, David Xu wrote:
> > Daniel Eischen wrote:
> >
> >> I don't think it is as big a change as you think it is.  We already
> >> have several layers of priorities (interrupt, time-share, idle, ?).
> >> All threads belong to these classes.  As long as priority inheritence
> >> works, there should be no problems.  The problems seem to occur when
> >> we try to inject artificial priorities into threads, like using
> >> msleep().  I think we are better off just letting threads run based
> >> on their own base priority and whatever their inherited priority is.
> >> 
> >
> > For test purpose, you may try to ignore thread priority parameter
> > in msleep(), I didn't test this, but it does change the FreeBSD
> > behavior. I don't know any side effect since I am unable to test
> > all applications in the world, maybe you can start a project to hack
> > it ?
> I'll take a look at trying that.  I should be able to figure out
> how to get msleep to ignore the priority.  But I think the missing
> piece is the interrupt routines - they need to create their mutexes
> and CVs so that they are more like priority ceiling mutexes.  Any
> thread (even non-interrupt threads) that takes one of these mutexes
> needs to have its priority raised as well as blocking the interrupt
> (for fast interrupts anyway) until the mutex is released.

One issue is that some places actually use the sleep priority for other
decisions.  (For example, we dont' swap out threads at PSOCK or higher.)  
You'd need to fix this logic in another way.  Solaris also bumps the priority 
of threads that acquire a read lock on a rwlock to a kernel-level priority to 
work around lack of priority propagation for readers.

An alernative to that is to bump the priority of threads that are in the 
kernel to a kernel-level priority on kernel-entry, but then you have to be 
careful about threads that are just waiting for the CPU and not a lock or 
other resource or all threads will effectively be scheduled at kernel-level 

One thing I have wanted to do as a small step is to add a sched_sleep_prio() 
for the msleep(9) priority (along iwth a get_sleep_prio() or some such for 
places that want to check PSOCK) and let the scheduler factor that into the 
actual priority but don't enforce that the msleep(9) arg actually sets the 

I do think cv's don't need to have priorities.  I'm not sure that mutexes for 
drivers need priorities as in Solaris since priority propogation should 
already handle that case if the mutex is needed by an ithread.

John Baldwin

More information about the freebsd-threads mailing list