[cpp-threads] Prism 0.9.1, and further on the effects of races

[Peter Dimov]

Herb Sutter wrote:

> The example is this:
>
>   class Base {
>   public:
>     Base() { /* some work */ }
>     virtual void BaseFunc() { }    // vtable slot 0
>   };
>
>   class Derived : public Base {
>   public:
>     Derived() { /* some work */ }
>     virtual void DerivedFunc() { } // vtable slot 1
>   };
>
> And we have:
>
>   thread 1: global_ptr = new Derived();
>
> With no constraints, this could execute as:
>
>             global_ptr = (Derived*)operator new( sizeof(Derived) );
>             global_ptr->vptr = &Base::vtable;     // a
>             global_ptr->Base ctor body;
>             global_ptr->vptr = &Derived::vtable;  // b
>             global_ptr->Derived ctor body;
>
> And in a race we perform:
>
>   thread 2: global_ptr->DerivedFunc();            // c

This isn't a problem in either model A (undefined behavior) and model B 
(global_ptr has an undefined value in the event of a race). In both cases, 
the (c) statement is allowed to trap.

It is only a problem if a read that participates in a race is constrained to 
only return one of the possible values that the variable could hold if the 
race was resolved in a sequentially consistent manner, but this is generally 
not true for non-atomic variables (if it were, we wouldn't need raw 
atomics.)