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