On Wed, 28 Feb 2001, Andreas Dilger wrote:
> Andreas Gruenbacher writes:
> > On Mon, 26 Feb 2001, Stephen C. Tweedie wrote:
> > > A set-and-return-old-value operation will let you work on multiple
> > > files at once. It won't guarantee atomicity but it will let you
> > > detect and backoff from any collisions. For atomicity, however, you'd
> > > still need extra locking.
> >
> > I thought we had dismissed that. The example against
> > set-and-return-old-value ("saro" below) I gave a while ago was that is
> > would lead to inconsistencies. Here's another example. Consider reliably
> > incrementing a counter:
> >
> > process A process B
> > --------- ---------
> > read = 1
> > read = 1
> > saro(1+1) = 1 -- fine
> > read = 2
> > saro(2+1) = 2 --fine
> > saro(1+1) = 3 -- oops!
> ^ this will actually be "2" and not "3"
^ Sorry, but you are wrong. "3" is the
value process A has set before. I'm
of course talking about process A
and B accessing the same counter.
>
> I'm not sure what you are getting at with the following:
>
> > -- critical section!
> > set(3) -- back off
Process B causes the system to be in an invalid state, since the counter
is set to a lower value than it was before. If it fails to roll back that
change for any reason, or if another process happens to be faster, errors
occur.
> Actually, I don't think the SARO implementation will work as you describe
> above. What would actually happen is:
>
> process A process B
> --------- ---------
> read = 1
> read = 1
> new = 1+1 = 2
> saro(2) = 1 -- fine (we got old value back)
> read = 2
> new = 2+1 = 3
> saro(3) = 2 -- fine (we got old value back)
> new = 1+1 = 2
> saro(2) = 2 -- oops! (we didn't get old value)
^ no, "3" :-)
Got it?
Cheers,
Andreas.
------------------------------------------------------------------------
Andreas Gruenbacher, [EMAIL PROTECTED]
Contact information: http://www.bestbits.at/~ag/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
