From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <007a01c022c3$d36bd340$926114d4@cz99.cz>
From: "Jakub Jermar" <jj@comberg.cz>
To: "9fans" <9fans@cse.psu.edu>
References: <20001110023525.CC1E7199E4@mail.cse.psu.edu> <05a001c04af7$0b262280$0ab9c6d4@cybercable.fr>
Subject: Re: [9fans] sleep(), sched() and ilock()
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
Date: Wed, 20 Sep 2000 07:27:42 +0200
Topicbox-Message-UUID: 2734e704-eac9-11e9-9e20-41e7f4b1d025

> multi-processor or not, a quick squiz at the lyons'
> commentary would explain a lot.
>
> you can derive a lot from first principles...
>

I am not familiar with the lyons's commentary (several days ago, I read some
bad criticism on it in 9fans), but I am pretty familiar with the principles
of interrupt and lock protecting.

I exactly know what the code is doing and what is it used for, but I can't
distinguish between the goals and the consequences (or -if you want- side
effects). Again, I don't ask about the functionality, I just want to know
what is the goal and what is the consequence.

As for the multi- versus uni-processors: there are important issues that
make the behaviour different.
As an evidence of this, you can find uni-processor branches of code that try
to avoid deadlock, which simply cannot happen on SMP (in the same
situation). A good example of what I've just said is ilock() itself.

Jakub Jermar