Re: [boost] [Interprocess] Experimental Win32 Mutexes

Subject: Re: [boost] [Interprocess] Experimental Win32 Mutexes
From: Brink, Robert (GE Aviation, US) (robert.brink3_at_[hidden])
Date: 2012-11-12 07:56:49

> 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.

The problems I was having was from performance.  I had roughly 20 processes that would allocate some shared memory every 50ms or so.  Periodically each process would slow to a crawl while the machine became sluggish.  Looking at the problem in Process Explorer I saw each process was reporting ~1,500,000 context switches per second. (Normally ~100/sec)  I attached a debugger and sure enough it stopped right in the shared memory allocator mutex.

Once I switched to the new algorithm, I no longer see the massive spike in context switches.  I did not notice any adverse effect to the execution speed. Though even if there was a small penalty I'd pay it to avoid the large spikes.

> 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.

I'm not sure about other use cases, but in my application I don't use many mutexes in shared memory.  It is mainly the allocation mutex that everyone uses and maybe 100-200 ones that are only used by 2-3 processes.  I don't think that I will approach those limits, but I can't speak for others.

> 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.

I was mostly curious if there were known problems.  Because this has improved my behavior significantly I will probably continue to run on this implementation.  I will be sure and post to the group if I run into any problems.

I have control over all processes that are connecting to this shared memory and they all are released in lock-step at this point.  I should be able to handle any future ABI changes without issue.

Thanks for the response.

Rob