Boost logo

Boost Users :

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

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


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at