Re: [Boost-users] EXTERNAL: Re: Poor/erratic boost::interprocess named_semaphore performance

Subject: Re: [Boost-users] EXTERNAL: Re: Poor/erratic boost::interprocess named_semaphore performance
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2012-02-13 15:21:17

El 13/02/2012 18:08, Davidson, Josh escribió:
> Thanks for the information.  I did briefly peek at the code and when
> I saw WaitForSingleObject, I assumed the handle was an actual win32
> semaphore.  Obviously there's a trade-off, and I have an agenda, but
> would it be reasonable to deviate from POSIX lifetime on semaphores
> just like what was done for shared memory?  Of course, this could
> break existing code, but if I'm not mistaken, a similar change was
> made in 1.48 for shared memory.

Yes, existing code was sadly broken, but lifetime semantics remained 
under POSIX rules (POSIX allows preserving shared memory between 
reboots, as shm might be implemented as mapped files). I hope to fix COM 
issues to get again kernel persistence, but I'll need some help from 
experienced windows programmers.

In 1.49 beta there is some native-windows implementations of mutex, 
condition, etc., but those are disabled (search for 
BOOST_INTERPROCESS_USE_WINDOWS) until I test them a bit and I choose a 
absolutely-ABI-breaking release. Named semaphores are not yet 
implemented using winapi calls and should be implemented in that 
absolutely-ABI-breaking release . The idea would be:

-> Create a temporary file representing the semaphore. That file stores 
a count when the last process attached to the semaphore is detached.
-> Use file id with a "prefix bips." as global semaphore name in the 
system: "Global\prefix bips.XXXXXXXXXXXXXXXXXXX"
-> Create on demand (open or create) a windows named semaphore with all 
access permissions (permissions are checked on the file). If semaphore 
was created, use file count as initial value.
-> Write sem status to file at semaphore close. Use native file locking 
to serialize access to the file.

This strategy is used by cygwin 1.7. This has a weak point if the last 
process attached to a semaphore dies, as the semaphore count won't be 
correctly written to the file (and the windows semaphore will dissapear. 
If another process opens the semaphore, the semaphore count won't be 
correct.

If anyone discovers a more robust strategy, let me know ;-)

Ion