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