read_write_mutex assertion on multiprocessor Wintel
As I reported earlier, read_write_mutex asserts in debug mode (VC71), apparently seeing false wake-ups on a condition variable. I was able to do this with just a simple group of threads locking a RWM in tight loops, with one writer and a few readers. The new information is that I am runing this on a dual-Xeon with hyper-threading enabled (so four apparent CPU's), and I'm thinking that maybe boost libs don't get exercised on this kind of hardware very much. Is is possible that a condition::notify_all() happens on each processor? Has anyone else seen this? For now, I just removed the asserts and rebuilt. Synchronization seems to be unaffected in my real-world stress test of RWM. jh
jkharris7@comcast.net wrote:
As I reported earlier, read_write_mutex asserts in debug mode (VC71), apparently seeing false wake-ups on a condition variable.
I was able to do this with just a simple group of threads locking a RWM in tight loops, with one writer and a few readers.
The new information is that I am runing this on a dual-Xeon with hyper-threading enabled (so four apparent CPU's), and I'm thinking that maybe boost libs don't get exercised on this kind of hardware very much.
I can assure you that they do, since that's a fairly typical configuration for our customers. However we aren't currently using read_write_mutex (or large numbers of threads).
Is is possible that a condition::notify_all() happens on each processor?
Threads are woken by the OS, not the processor. However, there is no guarantee that when a thread notifies a condition and then releases the associated mutex that one of the threads waiting on the condition will be the next to acquire the mutex. It is entirely possible that another thread waiting on that mutex will acquire it, though that's far more likely to happen in a multiprocessor machine. See http://www.lambdacs.com/cpt/MFAQ.html#Q94 for more information about spurious wakeups.
Has anyone else seen this?
For now, I just removed the asserts and rebuilt. Synchronization seems to be unaffected in my real-world stress test of RWM.
Since the assertions say that spurious wakeups don't happen, which is neither correct nor necessary for the correctness of the rest of the code, you are right to remove them. Ben.
participants (2)
-
Ben Hutchings
-
jkharris7@comcast.net