Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Jan 2001 13:08:40 -0800 (PST)
From:      Matthew Jacob <mjacob@feral.com>
To:        =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr>
Cc:        John Baldwin <jhb@FreeBSD.ORG>, alpha@FreeBSD.ORG, Doug Rabson <dfr@nlsystems.com>
Subject:   RE: Interrupt threads
Message-ID:  <Pine.LNX.4.21.0101021303460.14503-100000@zeppo.feral.com>
In-Reply-To: <Pine.LNX.4.10.10101022034150.1535-100000@linux.local>

next in thread | previous in thread | raw e-mail | index | archive | help



> 
> 
> On Tue, 2 Jan 2001, Matthew Jacob wrote:
> 
> > You switch to the process w/o changing IPL. It is resumed at the IPL of the
> > ithread that blocked. In the software way of looking at it, it inherits the
> > priority of the ithread until it releases the lock that caused it to be
> > resumed.
> 
> Just a tiny question and remark:
> 
> We must keep in mind (at it I have this in mind) that IPL is a thing local
> to a CPU but MUTEXes are global synchronisation objects.

That's absolutely correct.

> What happens if a ithread want to acquire a MUTEX owned by a thread 
> running on another CPU ?
> 
> In my $0.02 humble opinion, I think that we should probably be able from
> an ithread to just spinlock on a MUTEX that is already owned, unless we
> are believing in miracles.

This is why Solaris (and FreeBSD) makes a distinction between Spin and
Adaptive locks. The default we have for all of this are adaptive locks- the
ithread that tries to snag a lock that's held elsewhere will cause a
reschedule.

For a single CPU case, the thread that holds the lock should be resumed so the
lock can be freed up as soon as possible. For the multiple CPU case, a spin
should occur. The net result is the same- the ithread wanting the lock that's
held elsewhere has to wait until that lock is clear. We've been fussing mostly
over the issue that interrupt passivating doesn't seem to occur as cleanly as
we'd like on all platforms.

What will help get rid of the awful inefficiencies that this will bring in
will be the active rewriting of drivers to choose locking strategies that will
avoid this. We're very early in this stage so that we have broad swaths where
things Just Don't Work Well(tm).


> 
> > > > 4. What defeated me immediately upon looking at Doug's stuff is all of the
> > > > thread pri seems to be a software construct, so has no real hardware
> > > > linkage. Additionally, I did not take the time to try and find an easy way to
> > > > find and reschdule the proc that holds a lock if I'm trying to acquire it
> > > > from
> > > > an ithread and am blocking. Seems to be a bit of work there.
> 
> IMO, the real issue is pointed here.

I don't understand this.


-matt




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0101021303460.14503-100000>