[CODE]

function get_lock( $key_name )
{
while ( !$cache->add( $key_name, 1, false, 30 ) ) { usleep(100); }
}

function release_lock( $key_name )
{
$cache->delete( $key_name );
}

get_lock(‘lock_A’);
// do stuff
release_lock(‘lock_A’);

[/CODE]

The difference here is that unlike increment(), the key does not need to exist in the memcache prior to obtaining a lock, and add() is atomic as well. (it will never return ‘true’ to more than one process — as opposed to set() for example)

One pitfall though which I didn’t realize right away is that unlike a traditional blocking semaphore, the processes waiting to run will not necessarily complete in the order in which they started. They don’t line up in a queue to complete on a first-come-first-server basis, instead the next process to obtain the lock happens to be the first one to attempt an add() command after the lock is released which is completely random.

For example, in the second one, users A and B hit this function very nearly simultaneously. A executes ->get($cache_id), then B does. A tests timestamp and determines it is stale, then B does the same thing. A tests the lock and it doesn’t exist. B tests the lock and it doesn’t exist for him either. A sets the lock. B sets the lock.

Now both users will do this work at the same time, and if it’s really critical that the work not be done more than once (IE, perhaps it can lead to a deadlock or some other system utilization or data integrity issue), you can have some problems here.

I might suggest using something like (for your first example):
while ($cache->increment($lock_name) > 1) {
$cache->decrement($lock_name);
usleep(100);
}
Or adapting the same idea to your second example:
if ($cacheIsStale && $cache->increment($lockName) == 1) {
// refresh cache
}
$cache->decrement($lockName);

Increment and decrement should be atomic operations, so there should be no concern about both users calling ->increment() nearly simultaneously only to discover that they both get back the same value. Though this may not be guaranteed in a multi-memcached-server setup; at least in such a scenario the window size for the race condition is dramatically smaller – and it’s as good as it gets given that memcached doesn’t natively offer true semaphores.