Howard Hinnant:

> For the moment consider that all mutex and cv operations are atomic.  
> They can not be interrupted (as if they were a single machine 
> instruction).  In this model your code is still not safe.  You have a 
> race:  Does the cv get destructed before cv.notify_all() is called?  
> The answer is that we don't know.  If it does, you have undefined 
> behavior.  You would be referencing a member of a destructed object.
>
> Can you construct code that will reliably test your question?  Your 
> current code does not.  If your question can not be tested, then the 
> answer becomes irrelevant.
>
> To be clear, your original code would be just as "correct" if you 
> commented out the cv.wait(l) in ~C().  Because of spurious wakeups, 
> this call to wait does not *reliably* have any effect whatsoever.

It doesn't seem possible to isolate the original problem without introducing SW-related issues, so from the practical point of view your reasoning is perfectly understandable, thanks for clarification. What irks me here, is that even when there are no "bug-activating" events (read, SW), and the sequence of executed instructions does not violate the specs in any way, the program is still allowed to fail. From the practical point of view, I agree, it doesn't matter. From the logical point of view though, I can't help noticing the inconsistence, since it is exactly "executed instructions" (program behaviour for each particular run, that is, not the source code as such, however many other issues might be in there) that the specs are talking about: "being in such-and-such state, we are allowed to execute such-and-such actions".

----
Vladimir