Date: Wed, 20 Sep 1995 01:23:12 -0500 (CDT) From: Mike Pritchard <mpp@mpp.minn.net> To: terry@lambert.org (Terry Lambert) Cc: nate@rocky.sri.MT.net, terry@lambert.org, davidg@root.com, hackers@freefall.freebsd.org Subject: Re: Coding style ( was Re: why is this not a bug in namei?) Message-ID: <199509200623.BAA08946@mpp.minn.net> In-Reply-To: <199509192128.OAA10722@phaeton.artisoft.com> from "Terry Lambert" at Sep 19, 95 02:28:35 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509200623.BAA08946>