Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 4 Oct 2004 20:49:39 +0200
From:      Peter Holm <peter@holm.cc>
To:        Stephan Uphoff <ups@tree.com>
Cc:        "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: scheduler (sched_4bsd) questions
Message-ID:  <20041004184939.GA8178@peter.osted.lan>
In-Reply-To: <1096911278.44307.17.camel@palm.tree.com>
References:  <1095468747.31297.241.camel@palm.tree.com> <1096496057.3733.2163.camel@palm.tree.com> <1096603981.21577.195.camel@palm.tree.com> <200410041131.35387.jhb@FreeBSD.org> <1096911278.44307.17.camel@palm.tree.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 04, 2004 at 01:34:38PM -0400, Stephan Uphoff wrote:
> On Mon, 2004-10-04 at 11:31, John Baldwin wrote:
> > On Friday 01 October 2004 12:13 am, Stephan Uphoff wrote:
> > > On Wed, 2004-09-29 at 18:14, Stephan Uphoff wrote:
> > > > I was looking at the MUTEX_WAKE_ALL undefined case when I used the
> > > > critical section for turnstile_claim().
> > > > However there are bigger problems with MUTEX_WAKE_ALL undefined
> > > > so you are right - the critical section for turnstile_claim is pretty
> > > > useless.
> > >
> > > Arghhh !!!
> > >
> > > MUTEX_WAKE_ALL is NOT an option in GENERIC.
> > > I recall verifying that it is defined twice. Guess I must have looked at
> > > the wrong source tree :-(
> > > This means yes - we have bigger problems!
> > >
> > > Example:
> > >
> > > Thread A holds a mutex x contested by Thread B and C and has priority
> > > pri(A).
> > >
> > > Thread C holds a mutex y and pri(B) < pri(C)
> > >
> > > Thread A releases the lock wakes thread B but lets C on the turnstile
> > > wait queue.
> > >
> > > An interrupt thread I tries to lock mutex y owned by C.
> > >
> > > However priority inheritance does not work since B needs to run first to
> > > take ownership of the lock.
> > >
> > > I is blocked :-(
> > 
> > Ermm, if the interrupt happens after x is released then I's priority should 
> > propagate from I to C to B.  
> 
> There is a hole after the mutex x is released by A - but before B can
> claim the mutex. The turnstile for mutex x is unowned and interrupt
> thread I when trying to donate its priority will run into:
> 
> 	if (td == NULL) {
> 			/*
> 			 * This really isn't quite right. Really
> 			 * ought to bump priority of thread that
> 			 * next acquires the lock.
> 			 */
> 			return;
> 		}
> 
> So B needs to run and acquire the mutex before priority inheritance
> works again and does not get a priority boost to do so. 
> 
> This is easy to fix and MUTEX_WAKE_ALL can be removed again at that time
> - but my time budget is limited and Peter has an interesting bug left
> that has priority.

I'm not closer to being able to create this panic in a controlled way.
After a whole day of different tests I finally got this panic:
http://www.holm.cc/stress/log/cons81.html. The trigger seems to be one
particular Java applet, but it is not easily reproduceable.

- Peter

> 
> > If the interrupt happens before x is released, 
> > then the final bit of propagate_priority() should handle it since it resorts 
> > the turnstile's thread queue so that C will be awakened rather than B.
> 
> Agreed.
> 
> 	Stephan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041004184939.GA8178>