Is incr/decr atomic in multithread mode?
Marc
marc at facebook.com
Mon Feb 25 08:38:22 UTC 2008
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 get_item(k)
Ti unlokc(h)
Td lock(h)
Td get_item(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 get_item(k)
Ti unlokc(h)
Ti lock(h)
Ti do_add_delta(i)
Ti unlock(h)
Td lock(h)
Td get_item(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 as long
as there are referents.
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