The subject is misleading, but hopefully eye-catching :-) I do understand that this is not an interprocess bug, but more of a result of how upgradeable locks work. But the behavior can be dangerous, as will be seen. What I've got happening is that one process locks the mutex recursively (sharable, of course). And this works (most of the time), since it is okay to lock the mutex shareably any number of times (even if it is within the same thread). But the problem occurs when a writer (in another thread) manages to get inbetween these lockings, when we get this sequence thread A locks mutex shareably thread B waits for exclusive lock thread A waits for sharable lock Since the upgradable mutex is written so that if there is an exclusive locker waiting it doesnt let any more sharable lockers in this will deadlock. Something that explains this could be useful in the interprocess documentation. Or, maybe the problem could be solved. I see two ways: 1. Detect recursive sharable locking, so that my thread A would always get an exception when trying to lock a lock that I've already got (it is a recipe for disaster) 2. Allow recursive sharable locks. If you've got the lock it's okay to take it again. Since I'm not really a fan of recursive locking (the above locking is a mistake, really) I think I would prefer solution 1 of these two. (I'm fixing my code to not be recursive now, but I thought this might be of interest to either Ion or anyone using boost interprocess.) Cheers Lars