From owner-freebsd-hackers  Tue Sep 19 23:23:43 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id XAA20307
          for hackers-outgoing; Tue, 19 Sep 1995 23:23:43 -0700
Received: from mpp.minn.net (mpp.Minn.Net [204.157.201.242])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA20287
          for <hackers@freefall.freebsd.org>; Tue, 19 Sep 1995 23:23:39 -0700
Received: (from mpp@localhost) by mpp.minn.net (8.6.11/8.6.9) id BAA08946; Wed, 20 Sep 1995 01:23:13 -0500
From: Mike Pritchard <mpp@mpp.minn.net>
Message-Id: <199509200623.BAA08946@mpp.minn.net>
Subject: Re: Coding style ( was Re: why is this not a bug in namei?)
To: terry@lambert.org (Terry Lambert)
Date: Wed, 20 Sep 1995 01:23:12 -0500 (CDT)
Cc: nate@rocky.sri.MT.net, terry@lambert.org, davidg@root.com,
        hackers@freefall.freebsd.org
In-Reply-To: <199509192128.OAA10722@phaeton.artisoft.com> from "Terry Lambert" at Sep 19, 95 02:28:35 pm
X-Mailer: ELM [version 2.4 PL24 ME7a]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1471      
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

Terry Lambert wrote:

[SNIP]

> If on the other hand, you are objecting to the need for single entry/exit,
> I can justify this in terms of adding kernel multithreading and SMP locks
> in such a way as to cause them to "go away" in the Uniprocessor or non
> multithreading case.

I used to work for Cray Research back when they were working on
getting their multithreading kernel working and ready for release.
Depending on the function, single entry/exit functions could be a real 
pain the the ass.  For efficiency reasons, we would lock either the 
entire array, individual elements of the array, or even individual
variables in some cases.  In some routines, the single entry/exit idea 
just didn't fly.  Either you held the lock for much longer than you 
needed to, or you wound up having to keep track of which locks you had 
and then release them on exit.  When you have 16 - 64+ processors 
possibly wating for a lock, you never wanted to keep a lock any longer 
than needed.  A lot of the time it was much easier to code something
as follows:

	XXX_LOCK();
	...
	if (error_condition) {
		XXX_UNLOCK();
		return (EWHATEVER);
	}
	...
	XXX_UNLOCK();

Rather than:

	XXX_LOCK();
	have_xxx_lock = 1;
	...
	if (error_condition) {
		error = EWHATEVER;
		goto done;
	}
	...
	XXX_UNLOCK():
	have_xxx_lock = 0;
done:
	if (have_xxx_lock)
		XXX_UNLOCK():
	return (error);
-- 
Mike Pritchard
mpp@mpp.minn.net
"Go that way.  Really fast.  If something gets in your way, turn"