Is incr/decr atomic in multithread mode?

[Marc]

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