Date: Fri, 21 Dec 2007 13:36:44 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-threads@freebsd.org, Daniel Eischen <deischen@freebsd.org> Cc: David Xu <davidxu@freebsd.org> Subject: Re: threads/118910: Multithreading problem Message-ID: <200712211336.44996.jhb@freebsd.org> In-Reply-To: <Pine.GSO.4.64.0712210310090.20251@sea.ntplx.net> References: <200712210700.lBL707MZ002071@freefall.freebsd.org> <476B7476.3010509@freebsd.org> <Pine.GSO.4.64.0712210310090.20251@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712211336.44996.jhb>