Subject: Re: newlock
To: Bill Studenmund <email@example.com>
From: Lars Heidieker <firstname.lastname@example.org>
Date: 09/06/2006 11:20:00
-----BEGIN PGP SIGNED MESSAGE-----
On 6 Sep 2006, at 00:40, Bill Studenmund wrote:
> On Mon, Sep 04, 2006 at 01:35:02PM -0700, Garrett D'Amore wrote:
>> David Laight wrote:
>>> On Sun, Sep 03, 2006 at 07:31:55PM -0700, Garrett D'Amore wrote:
>>>> Wrong. This works fine in Solaris. The spin mutex doesn't
>>>> automatically release the spl -- instead it releases a =20
>>>> _reference_ on
>>>> the spl. The spl is only dropped when the reference reaches zero.
>>> I've never seen that behaviour documented for Solaris...
>> It wouldn't be "documented", because that would be an internal
>> implementation detail.
>> I'm now looking the code, and I'm not so sure. I had always =20
>> assumed it
>> this to be this way, but reading the Solaris code, it looks like I =20=
>> be wrong here. If that's true, then there are a lot of buggy Solaris
>> drivers out there, including one or two that I've written. :-(
>> I'm going to investigate this further.
> Please do. This issue is very interesting to me. ;-)
The order of exiting from the mutexes is important as a spin mutex =20
(Solaris) changes the
ipl level depending on what it is and what the mutex wants but it =20
only increases the protection level
and saves the old level
lock_set_spl is the routine doing this. It is called from =20
The SPARC Version is in:
and if i read the intel version right they don't have real levels in =20
the 32bit version but in the 64bit version
so the problem with the unlock order Garrett describes might not =20
manifest in the 32bit version
Die mystischen Erkl=E4rungen gelten f=FCr tief;
die Wahrheit ist, dass sie noch nicht einmal oberfl=E4chlich sind.
-- Friedrich Nietzsche
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
-----END PGP SIGNATURE-----