threads/118910: Multithreading problem
John Baldwin
jhb at freebsd.org
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
priorities.
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
priority.
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