Unnamed POSIX shared semaphores

[Ivan Voras]

John Baldwin wrote:
> On Monday 01 June 2009 5:17:48 pm Bruce Simpson wrote:
>> Jilles Tjoelker wrote:
>>> If process-shared semaphores really work, then the above structure is
>>> not a pathological case. Effectively, sem_t is carved in stone. So
>>> process-private semaphores should continue to have most of their stuff
>>> in a separately allocated structure, to preserve flexibility.
>>>   
>> There was an inadvertent race in FreeBSD's POSIX semaphores which I 
>> fixed in HEAD and STABLE about 6 weeks before 7.2 was released.
>>
>> I believe process-shared POSIX semaphores now work -- the Python 
>> 'multiprocessing' regression test now runs to completion with no errors 
>> on both HEAD and STABLE.
> 
> The semaphores in recent 7 and 8 are definitely not process-shared (at least 
> not intentionally).  They may work across a fork accidentally, but you can't 
> store it in an mmap() region and share it with an arbitrary process.
> 

On a completely unrelated subject I was reading about PHP APC cache
where they have the same need - cross-process locking with locks
embedded in data structures and they have adopted userland spinlock code
from PostgreSQL:

http://www.scribd.com/doc/3288293/brian-shireapc-facebook

(spin)locks are not the same as sempahores but maybe it will help the OP
or anyone else trying to implement this feature:

http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.h?revision=3.4&view=markup

http://cvs.php.net/viewvc.cgi/pecl/apc/pgsql_s_lock.c?revision=3.3&view=markup