Linus Torvalds wrote:
quoted text
> Looking at the memcached operations, they have the "read" op (aka "get"), 
> but they seem to have no "read-for-fill" op. So memcached fundamentally 
> doesn't fix this problem, at least without explicit serialization by the 
> client.
>   

Actually, memcached does support an operation that would work for this: 
the "add" request, which creates a new cache entry if and only if the 
key is not already in the cache. If the key is already present, the 
request fails. You can use that to implement a simple named mutex, and 
it supports a client-specified timeout. The one thing it doesn't support 
that you described is a notion of deleting a key when a particular 
client disconnects, but as you say, that should only happen in the case 
of buggy clients anyway.

Mind you, I'm not convinced memcached is necessarily the right answer 
for this problem, but it does provide a way to implement the required 
locking semantics.

BTW, I'm one of the main contributors to memcached, so if it does end up 
looking like a good choice except for some minor issue or another, I may 
be able to tweak it to cover whatever is missing. For example, the 
"delete a key on disconnect" thing would be fairly straightforward, if 
it's actually necessary in practice.

-Steve

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html