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