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"
I'm not sure what you are getting at with the following:
> -- critical section!
> set(3) -- back off
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)
(*)
new = 2+1 = 3 -- update based on current EA value
saro(3) = 2 -- fine (we got old value back)
at (*) we could have any number of other clients changing the EA value,
and as long as it is back to "2" before process B does saro(3), the
EA update will succeed. This is the correct behaviour.
If the EA held a timestamp or something that was never returned to
the original state, then it is possible process B will be starved for
updating the EA on a very busy system, but it would never get into an
inconsistent state unless the application was buggy. This places
some burden on the application writer, but IMHO it is impossible to
do otherwise.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
