To elaborate my take on the above scenario, I would expect that client A would get 2, and client B would get 3. The final result in memcached would be 3 if anyone else does a 'get' afterwards. I would certainly NOT expect two clients to ever receive the same number from an incr. In fact, if it ever did, that would break quite a number of my processes actually.
On Tue, Feb 26, 2008 at 11:38 AM, dormando <[EMAIL PROTECTED]> wrote: > Steve Chu wrote: > > I'm sorry that my expression may confuse you. I try to make it more > clear. > > My requirement is that clients to incr/decr a value must be atomic, > > that get from slabber and > > add 1 must be an atomic operation according to clients(php clients or > > libmemcached etc.). If two clients incr a value 1, the value should > > be 3, not that B client overwrite the value, and the final value is > > still 2. This operation in Non-thread is atmoic, because they are not > > in concurrent environment, and only one event is processed one time. > > > > But now I found in multithread version it is not atomic, if put the > > item_get in add_delta, this may be done, but too many locks. > > > > I wonder if you understand my meaning, anyway, > > > > I understand your meaning. It is actually atomic, if two threads hit > that code at the same time, the final value will be 3, it will not be two. > > The value in the slabber is updated *inside* of add_delta, so there's no > way it could end up being 2 if two threads incr it from 1. > > -Dormando > -- "Be excellent to each other"
