RES: Is the add command atomic ?

dormando dormando at rydia.net
Wed Mar 26 20:07:47 UTC 2008


Fausto Richetti Blanco wrote:
> I want to know if it is possible that two concurrent processes do this:
> 
> $mc->add('user1lock', 10);
> 
> at the same time and get 'true' as the return. This is what I mean by 
> 'atomic'.

Yes that is atomic.

> I understand what you said about "the small chance it could get 
> ejected". Is there a way to configure memcached to never discard data ? 
> What do you mean by "depending on other factors" ? If the memory 
> available to memcached is guaranteed to have enough space to store all 
> my locks and I do not set expiration on any keys, can memcached still 
> discard some locks ?

Run it in -M mode to disable the LRU. Be careful about setting items 
that never expire and don't naturally get deleted :) It'll give you 
SERVER_ERROR out of memory instead of setting the item.

I'd also just be wary based on the fact that it's not formally 
guaranteed. A memcached instance can be restarted, flap, etc. I want to 
add more formal locks to memcached, in that the object is immutable 
until the lock is released or the connection holding it is closed. 
Others can choose to block or fail just how mysql does GET_LOCK / 
RELEASE_LOCK. That'd make it a bit safer to use this design pattern and 
add the option to serialize a lock queue.

-Dormando

> Fausto Richetti Blanco
> CWI Software - CMMI Nível 2
> Desenvolvimento
> (51) 3264-3737
> http://www.cwi.com.br
> -----Mensagem original-----
> De: dormando [mailto:dormando at rydia.net]
> Enviada em: quarta-feira, 26 de março de 2008 15:58
> Para: Fausto Richetti Blanco
> Cc: memcached at lists.danga.com
> Assunto: Re: Is the add command atomic ?
> 
> What do you mean by "atomic" ?
> 
> The add operation itself is "atomic", ie:
> 
> $mc->add('user1lock', 10);
> 
> ... will bail if the key already exists, or return true if it did not 
> exist.
> 
> However:
> 
> $mc->add('user1lock', 10);
> 
> $mc->set('blah blah blah');
> 
> ... does _not_ *absolutely* guarantee the lock still exists by the time
> set gets called. 99.9995% of the time it'll still be in cache, but
> there's a small chance it could get ejected, which gets wider when
> there's more time between the add call and the set call, and depending
> on other factors.
> 
> So we can't say it's atomic, it's more like a ghetto lock that usually
> works. You can use it for situations where you want to reduce the number
> of processes running something in parallel, but you can't use it if you
> need to _guarantee_ they won't run it in parallel.
> 
> -Dormando
> 
> Fausto Richetti Blanco wrote:
>  > Hello,
>  >
>  > 
>  >
>  >             I've found this entry on the FAQ:
>  >
>  > 
>  >
>  > "One should be mindful about possible issues in populating or
>  > repopulating our cache. Remember that the process of checking memcached,
>  > fetching SQL, and storing into memcached, is **not** atomic at all!"
>  >
>  > 
>  >
>  >             I know it's talking about the entire process, but I want to
>  > confirm with you whether the add function is atomic or not. I want to
>  > use memcache to simulate locking and this atomicity is very important to
>  > the whole process.
>  >
>  > 
>  >
>  > Thanks in advance,
>  >
>  > 
>  >
>  > **Fausto Richetti Blanco**
>  > **CWI Software - CMMI Nível 2**
>  >
>  > Desenvolvimento
>  > //(51) 3264-3737//
>  >
>  > http://www.cwi.com.br <http://www.cwi.com.br/>
>  >
>  > 
>  >
> 



More information about the memcached mailing list