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.
Things could be improved a bit not calling thread_yield in every loop step in spin_semaphore::wait() (Boost 1.49). I am currently using 1.49 Beta 1.
Josh -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Ion Gaztañaga Sent: Monday, February 13, 2012 5:55 AM To: Boost User List Subject: EXTERNAL: Re: [Boost-users] Poor/erratic boost::interprocess named_semaphore performance El 13/02/2012 11:25, Nathaniel J Fries escribió:
From quickly looking at the header files it appears that there is no Windows implementation of the synchronization portion of the library, and instead a generic user-space mechanism is used. All POSIX systems (Linux, Mac) use POSIX mechanisms.
It appears relatively simple to port, if you're already familiar with the Windows API code for it. The POSIX implementation of semaphores is done in fewer than 50 lines.
Not so easy if you want to achieve the same POSIX lifetime guarantees. There is an implementation in my head to achieve better windows performance using windows native synchronization primitives, but that would need to wait until I find some time as I have tons of bugs, ideas and requests for Container, Intrusive and Move. Things could be improved a bit not calling thread_yield in every loop step in spin_semaphore::wait() (Boost 1.49). Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users