From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <20100206161207.GA31545@centaur.acm.jhu.edu>
References: <20100206161207.GA31545@centaur.acm.jhu.edu>
Date: Sat,  6 Feb 2010 16:12:07 -0800
Message-ID: <dd6fe68a1002061612u754bf41ic04fbcfa2c2f2b4b@mail.gmail.com>
Subject: Re: [9fans] kenfs question?
From: Russ Cox <rsc@swtch.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: multipart/alternative; boundary=000e0cd2170e0436b0047ef789c4
Topicbox-Message-UUID: cf071356-ead5-11e9-9d60-3106f5b1d025

--000e0cd2170e0436b0047ef789c4
Content-Type: text/plain; charset=UTF-8

>
> ilock() (pc/lock.c) calls splhi() and then calls lock(). If that lock were
> contended, how would the system not stop? And on a UP system, if you're
> inside an splhi() block,
> why would you need to take an uncontended lock?
>

ilock is for locks that get used both in normal procs
and in interrupt handlers.  Using splhi makes sure
that the interrupt handler does not get started on the
same cpu while the proc holds the lock, which would
cause a deadlock.

If there were no interrupts involved, the lock would be
managed with lock/unlock instead of ilock/iunlock.

On a uniprocessor you could get away with splhi/splx
instead of ilock/iunlock, but it's easier and more portable
to program as if always on a multiprocessor.

Russ

--000e0cd2170e0436b0047ef789c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">ilock() (pc/lock=
.c) calls splhi() and then calls lock(). If that lock were contended, how w=
ould the system not stop? And on a UP system, if you&#39;re inside an splhi=
() block,<br>

why would you need to take an uncontended lock?<br></blockquote><div><br></=
div><div>ilock is for locks that get used both in normal procs=C2=A0</div><=
div>and in interrupt handlers. =C2=A0Using splhi makes sure</div><div>that =
the interrupt handler does not get started on the</div>
<div>same cpu while the proc holds the lock, which would</div><div>cause a =
deadlock.</div><div><br></div><div>If there were no interrupts involved, th=
e lock would be</div><div>managed with lock/unlock instead of ilock/iunlock=
.</div>
<div><br></div><div>On a uniprocessor you could get away with splhi/splx</d=
iv><div>instead of ilock/iunlock,=C2=A0but it&#39;s easier and more portabl=
e</div><div>to program as if=C2=A0always on a multiprocessor.</div><div><br=
></div>
<div>Russ</div></div>

--000e0cd2170e0436b0047ef789c4--