Is incr/decr atomic in multithread mode?

Marc marc at facebook.com
Mon Feb 25 08:51:18 UTC 2008


[Somehow I fired that off before finishing]

That's true but so what?  There is no global notion of which thread is
"first".  Holding a lock over the entire operation doesn't make any
difference to the order in which updates are actually applied to a value, so
there is no need to hold it.

For example let's say thread Ti wants to increment and thread Td wants to
delete with a non-0 expiration time and the following ordering occurs

    Ti lock(h)
    Ti item_get(k)
    Ti unlokc(h)
    Td lock(h)
    Td item_get(k)
    Td unlock(h)
    Td lock(h)
    Td delete(k, 3600)
    Td unlock(h)
    Ti lock(h)
    Ti do_add_delta(i)
    Ti unlock(h)

This is the same as:
    Ti lock(h)
    Ti item_get(k)
    Ti unlokc(h)
    Ti lock(h)
    Ti do_add_delta(i)
    Ti unlock(h)
    Td lock(h)
    Td item_get(k)
    Td unlock(h)
    Td lock(h)
    Td delete(k, 3600)
    Td unlock(h)

Because the delete simply moves items into the deferred delete queue and
processes asynchronously in the delete handler.

The point here is that while holding a lock over both operations could
result in different results, no client has the ability to detect that, so no
guarantee of atomicity is violated.  If a global lock resulted in the delete
being done before the increment and thus a NOT_FOUND returned to the
incrementing client that scenario would be indistinguishable from the
current case without a global lock and thread Td just happening to get in
first and completing all processing before Ti even gets to call item_get.
Since the states are indistinguishable, there is no need for a lock over
both operations.

 2/24/08 10:25 PM, "Steve Chu" <stvchu at gmail.com> wrote:

> In 'process_arithmetic_command' function:
> We first do item_get from slabs and then do add_delta to incr/decr the value.
> 
> My question is:
> Is this atomic in multithread mode? Item_get is atomic and so is
> add_delta because they are protected by mutex. But the entire two
> operations seems NOT atomic. Two threads can both do item_get with
> same key, then both incr it, and write back.
> 
> Anybody can tell me whether it is a bug or not?
> 
> Regards,
> 
> Steve Chu




More information about the memcached mailing list