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