Date: Fri, 21 Dec 2007 15:41:41 +0800 From: David Xu <davidxu@FreeBSD.org> To: Daniel Eischen <deischen@FreeBSD.org> Cc: freebsd-threads@FreeBSD.org Subject: Re: threads/118910: Multithreading problem Message-ID: <476B6E35.508@freebsd.org> In-Reply-To: <Pine.GSO.4.64.0712210228030.20251@sea.ntplx.net> References: <200712210700.lBL707MZ002071@freefall.freebsd.org> <Pine.GSO.4.64.0712210228030.20251@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > On Fri, 21 Dec 2007, David Xu wrote: > >> The kernel condition variable implementation is problematic, a >> thread sleeping on a condition variable does not raise its priority >> to some I/O priority, but most code will raise thread's priority to some >> level with msleep(). The code in sound driver use lots of cv_broadcast >> call(), it does not raise thread priority, this causes the music player >> does not have more chances to do I/O while other I/O bound applications >> will have. >> >> The kernel condition variable also causes top() to display incorrect >> priority because cv_wait does not update the priority but it is updated >> by cv_broadcastpri() which is too late for top to display. >> >> The kernel condition variable's initialization function should accept >> a thread priority parameter, and all thread sleep on the condition >> variable should use the priority. > > While your hypothesis of what is happening may be correct, I don't > think the solution is quite right. msleep() has to go away, at > least the priority parameter does. The kernel should be scheduling > based on thread priorities that are not artificially elevated by > parameters to msleep. > > The kernel CV and mutexes initialization functions should accept > something like Solaris interrupt cookies (see mutex_init() and > cv_init() in Solaris). All mutexes/CVs used by interrupt code > should initialize their CVs and mutexes with something like this. > I don't think they should be using a priority directly. > Oh, I don't want to change BSD's behavior, the FreeBSD in the past years does raise thread priority while sleeping, if msleep does not raise thread priority, I don't know if FreeBSD will still work as normal, by the way, your idea is a big change. Regards, David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?476B6E35.508>