Is incr/decr atomic in multithread mode?

dormando dormando at rydia.net
Tue Feb 26 06:32:15 UTC 2008


Fantastic: because that's what it does!

Clint Webb wrote:
> 
> 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 <dormando at rydia.net 
> <mailto:dormando at rydia.net>> 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"



More information about the memcached mailing list