threads/118910: Multithreading problem

[Ariff Abdullah]

On Fri, 21 Dec 2007 15:41:41 +0800
David Xu <davidxu at FreeBSD.org> wrote:
> 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 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.
> > 
> > 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.
> 

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 ........
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20071221/937fb9f3/attachment.pgp