Subject: Re: sunita's bufmgr bug

From: [email-masked] (Paul M. Aoki)
Date: Wed, 08 Mar 95 21:47:45 -0800

"Andrew K. Yu" <[email-masked]> writes:
> hey Paul, we seem to have found the bug (that you introduce last
> July while you're optimizing the bufmgr).

look carefully at the rcs history.

the last two revisions strictly increased the amount of code covered
by mutexes.  for example, the tag operations in BufferReplace weren't
mutexed at all before the last revision.  this sort of worked on suns
but didn't work so well on alphas because of their memory consistency
model.

the business of giving up the mutex in BufferAlloc before calling
BufferReplace has *always* been there.  look at any previous revision.
the OPTIMIZE_SINGLE business is something that i added that *avoids*
giving up the mutex during the i/o when defined (evidently the more
correct behavior anyway, oh well) because semop(3) is so expensive
under ultrix (no TASlocks).  without -DOPTIMIZE_SINGLE, BufferAlloc
has the same behavior that was there for the last 83 revisions. 
--
  Paul M. Aoki          |  University of California at Berkeley
  [email-masked]  |  Dept. of EECS, Computer Science Division (#1776) 
                        |  Berkeley, CA 94720-1776

---

From: "Andrew K. Yu" <[email-masked]>
Date: Wed, 8 Mar 1995 22:59:21 -0800

> > July while you're optimizing the bufmgr).

sorry, pointing finger wasn't my intent (although having the urge to shoot
someone after finding the bug isn't entirely an exaggeration :). The reason
why I'm looking at the log is to determine the extent of the damage. This
appears to be a common enough multi-user bug that someone must have
experienced it.

> BufferReplace has *always* been there.  look at any previous revision.

the bug seems to have creeped in when someone reorganize the order of the
calls between revs 1.79 and 1.80. (The bug doesn't happen to pre-1.79 code
because the tag has been inserted into the buffer table before doing I/O.
Releasing the lock at that point does no harm.)

I was just trying to determine whether I should alert mao.

-andrew