For those that encounter strange behavior in using sem_acquire() on resources generated by sem_get(). Have a look at sem_get()'s 4th parameter auto_release. It allows multiple acquisitions through reassignments to resource variables.

As you can see there were multiple semaphores set up with key 0.For any other integer sem_get works as expected. It returns another resource id pointing to the semaphore previously created and does not create another semaphore.

Watch out when you use fileinode() to get a unique semaphore key (as suggested in some comment on this or a related function) in conjunction with version control software: It seems, for example, SVN will change the inode. Using such a file will leave you with your mutex not working reliably and your system's semaphore pool being filled until further attempts to get a semaphore will fail. Use ipcs and ipcrm commands from linux-util-ng (on most distros probably) to examine/fix related problems.

// lets place a variable in thereshm_put_var ($data, $inmem, "test");// now lets get it back. we could be in a forked process and still have// access to this variable.printf("shared contents: %s\n", shm_get_var($data, $inmem));

This will not block on the second sem_aquire. Therefore, if you have functions or processes that utilize shared locks (>1 max_acquire) you will still need to provide a seperate lock mechanism (ie flock) for write access, making the sem_ functions useless.

Some more info, in flock, each reference to the lock file has it's own options (can be shared exclusive blocking non blocking etc), but apparently php's sem functions only support these options per semaphore, not per semaphore-reference.