Date: Fri, 21 Dec 2007 15:51:23 +0800 From: Ariff Abdullah <ariff@FreeBSD.org> To: David Xu <davidxu@FreeBSD.org>, Kuteynikov Dmitriy <kuteynikov@gmail.com> Cc: deischen@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: threads/118910: Multithreading problem Message-ID: <20071221155123.53f593a2.ariff@FreeBSD.org> In-Reply-To: <476B6E35.508@freebsd.org> References: <200712210700.lBL707MZ002071@freefall.freebsd.org> <Pine.GSO.4.64.0712210228030.20251@sea.ntplx.net> <476B6E35.508@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Signature=_Fri__21_Dec_2007_15_51_23_+0800_Q5T_2.6JEVZ_20Yl
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, 21 Dec 2007 15:41:41 +0800
David Xu <davidxu@FreeBSD.org> wrote:
> Daniel Eischen wrote:
> > On Fri, 21 Dec 2007, David Xu wrote:
> >=20
> >> 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 critical that require raising the priority are using
cv_broadcastpri(), not cv_broadcast(). See sys/dev/sound/pcm/channel.h
.
> >> 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.
> >=20
> > 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.
> >=20
> > 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.
> >=20
>=20
> 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.
>=20
With all due respect, the original poster issue are more to fluxbox
non-opaque window dragging implementation which require locking the
entire X server through XGrab/UngrabServer(), which in turns
preventing other client windows to update their own gui, blocking the
entire client operation. It has little or nothing to do with
threading.
Kuteynikov, go to fluxbox menu, and enable
"Opaque Window Moving/Dragging/Resizing" (or whatever it is).
--
Ariff Abdullah
FreeBSD
... Recording in stereo is obviously too advanced
and confusing for us idiot ***** users :P ........
--Signature=_Fri__21_Dec_2007_15_51_23_+0800_Q5T_2.6JEVZ_20Yl
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFHa3B7lr+deMUwTNoRAvZ3AKCgdJLyapGLqNu2+T/zjSSSh3furwCgr53W
iYBPzBcw+MtyanBXpRA5HBU=
=rcKN
-----END PGP SIGNATURE-----
--Signature=_Fri__21_Dec_2007_15_51_23_+0800_Q5T_2.6JEVZ_20Yl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071221155123.53f593a2.ariff>