Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk