Is incr/decr atomic in multithread mode?
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
Td delete(k, 3600)
This is the same as:
Td delete(k, 3600)
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
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?
> Steve Chu
More information about the memcached