Re: C++0x: release sequence

On Jun 16, 3:09 pm, Anthony Williams <anthony....@gmail.com> wrote:


In your example, yes, one have to use non-relaxed rmw. But consider
following example:

struct object
{
    std::atomic<int> rc;
    int data;

    void acquire()
    {
        rc.fetch_add(1, std::memory_order_relaxed);
    }

    void release()
    {
        if (1 == rc.fetch_sub(1, std::memory_order_release)
        {
            std::atomic_fence(std::memory_order_acquire);
            data = 0;
            delete this;
        }
    }
};

object* g_obj;

void thread1();
void thread2();
void thread3();

int main()
{
    g_obj = new object;
    g_obj->data = 1;
    g_obj->rc = 3;

    thread th1 = start_thread(&thread1);
    thread th2 = start_thread(&thread2);
    thread th3 = start_thread(&thread3);

    join_thread(th1);
    join_thread(th2);
    join_thread(th3);
}

void thread1()
{
    volatile int data = g_obj->data;
    g_obj->release(); // T1-1
}

void thread2()
{
    g_obj->acquire(); // T2-1
    g_obj->release(); // T2-2
    g_obj->release(); // T2-3
}

void thread3()
{
    g_obj->release(); // T3-1
}

From point of view of current C++0x draft this code contains race on
g_obj->data. But I think this code is perfectly legal from hardware
point of view.

Consider following order of execution:
T1-1
T2-1 - here release sequence is broken, because of relaxed rmw
T2-2 - but here release sequence is effectively "resurrected from
dead", because thread, which executed relaxed rmw, now execute non-
relaxed rmw
T2-3
T3-1