Linus Torvalds wrote:
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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html