Re: [boost] [Interprocess] Experimental Win32 Mutexes

Subject: Re: [boost] [Interprocess] Experimental Win32 Mutexes
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2012-11-11 18:09:08

El 09/11/2012 19:05, Brink, Robert (GE Aviation, US) escribió:
> I'm running Boost 1.52 on Windows 7, Visual Studio 2010.
>
> I noticed in sync\interprocess_mutex.hpp there is a windows mutex
> implementation that is hidden behind the
> BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION macro.  The comment
> indicates that it is "Experimental".
>
> Could someone shed some light on what is Experimental about it and
> what the general plans for this feature are?
>
> I was having a problem with many processes all spin-locking when
> allocating shared memory that I traced down to the old mutex
> implementation for shared memory.

Which kind of problem? Spinlocks are quite simple so unless it's a 
performance-related issue, I can't imagine what can be wrong with 
spinlock-based mutexes.

> I enabled the experimental feature
> in my local build ( by commenting out the above macro in the
> detail\workaround.hpp file) and it seems to fix my problems.  My
> performance is much improved.  But what are my risks for using this
> implementation?  I'm a little nervous to depend on something marked
> as "Experimental".

A better windows implementation was needed, but it's not easy to write 
it. I don't know of any PTHREAD_PROCESS_SHARED windows emulation. Cygwin 
does not even try to emulate it.

The implementation is not optimized, I had no time to test it 
thoroughly, and in some aspects it's a bit tricky (each process stores 
the already created synchronization handles in a header-only singleton 
implementation that stores the synchronization map into the current and 
max count of a named semaphore!). I also creates windows named resources 
(named mutexes, and semaphores) on the fly, I don't know if we'll hit 
some process or kernel related limits with this approach.

If you and some Interprocess users can test it and give some feedback, 
we could make them default in a future Boost release, but this will 
create a binary incompatibility in windows systems so we must be sure 
this implementation is better than the old one.

Before we break the ABI, we need to make sure performance is correct. 
Current implementation is suboptimal in many aspects (a hash and map 
lookup to obtain the handle of the primitive is overkill IMHO and 
performance might worse as the number of synchronization primitives 
grow). We maybe need to write a spinlock-based fast path and use named 
synchronization primitives in case of contention.

I'm glad to hear it worked for you, but I can't guarantee the 
implementation is well tested and the ABI will surely change. Any 
feedaback you could give me it would be very valuable.

Best,

Ion