Read

http://t3.dotgnu.info/blog/php/user-cache-timebomb

Also

http://php.net/apc_add

Imagine the following situation.

The cache under key $key is empty. Two threads simultaneously hit cache by calling apc_fetch( $key). Both receive false and begin generating the cache, after what the first thread reaches apc_add state first, calls apc_add( $key, $generatedData, $ttl), adds a cache, then the second thread reaches the apc_add and gets false as return code, which indicates that the second cache generating was the waste of time, because the cache was already generated by the first thread. That's what i'm talking about. See the following code:

$key ='test';
$ttl =60;
if( !($generatedData =apc_fetch( $key))) {
  // we see that no cache exists, generate it
  /*
   lots of expensive tasks...
  */
  $generatedData =get_cache_generating_result();
  // store the results in the cache
  if( apc_add( $key, $generatedData) ===false) {
    // OMG, another thread already rendered the same cache
    // i was rendering right now. That wasn't very nice
    // from another's thread side. I gotta tell this admin.
    trigger_error( 'Omg, someone is doing my job!', E_USER_ERROR);
  }
}
// success, operate on obtained data

As i mentioned before, if two threads enter the cache generating state, which IS POSSBLE in APC right now because of synchronization lack at stage of generating, both threads generate the same cache, and after one of these generating results just being thrown away.

What happens if PHP exits with a syntax error/segv inside the apc_lock() segment?

Generally the way I have handled this in the past for file-based caches is to touch() the previous cache file when it times out.  That is a fast operation which lets other processes use the old cache data while a single process is generating the new data.  Doing a fast touch() drastically reduces the size of the window for other processes to enter the expensive data generation section.  Depending on what you are actually doing, you should be able to adapt that sort of approach to your situation simply by checking an apc entry containing a timestamp or just a boolean flag.  I see no need for userspace locking for this.

t3 at freeshell dot in: well, the consequences of unexpected errors can be avoided by adding an implicit apc_unlock() call if apc is 'locked' at the end of request (implicit!).

rasmus at php dot net:
this behavior:
 if( !apc_fetch( 'somekey')) {
  apc_store( 'somekey');
 }
is not atomic, and will never be, thus, i cannot use the method you described to achieve the synchronization i need.

apc_add() is atomic.

if(!$lck=apc_fetch('lock')) {
  if(apc_add('lock',$_SERVER['REQUEST_TIME'])) {
    // got lock, proceed...
  } else {
    // someone beat us to it
  }
} else {
  // Someone else has the lock - check it...
}

Hmm, really... How i didn't think of abusing apc_add() before... Thank you very much rasmus.

People looking for solution to synchronize apc, use this code:

function apc_lock() {
 while( !apc_add( '_lock'))
  usleep( 500);
}

function apc_unlock() {
 apc_delete( '_lock');
}

Use these functions as i described above.
Once more, thanks rasmus :)

There is a serious trouble you can run into using this code. If script fails in a segment between apc_lock() and apc_unlock(), there will be a deadlock for all other threads trying to lock apc. 

Couple solutions:

1) Except writing error-safe code, try to set timeout for the lock variable of apc, e.g. call apc_add( $lockName, true, 5), this will lock apc for a max. of 5 seconds. After 5 seconds elapse, the locked cache will be unlocked implicitly.

2)
 function apc_lock( $emergencyAfter =5) {
   global $_APCLockID, $_APCLocked;
   while( !apc_add( '_lock', $_APCLockID =microtime( true), $emergencyAfter))
     usleep( 500);
   $_APCLocked =true;
 }
 function apc_unlock() {
   global $_APCLockID, $_APCLocked;
   if( $_APCLocked)
     if( apc_fetch( '_lock') ==$_APCLockID)
       apc_delete( '_lock');
   $_APCLocked =false;
 }

 then add error handler

 function custom_errorhndlr( $errno, $errmsg) {
   apc_unlock();// implicitly unlock apc on error
 }

 and use:

 set_error_handler( 'custom_errorhndlr');

 apc_lock();
 // do your job here
 //  note, if error occurs, custom error handler will
 //  implicitly unlock locked cache. if a hard error occurs,
 //  and script skips custom_errorhndlr, lock will be released
 //  implicitly after 5 seconds
 apc_unlock();

Anyway, despite that, this is not the best solution that can be available.