[Issue 9163] std.parallelism broken with extensive optimizations (gdc)

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=9163



--- Comment #10 from Johannes Pfau <johannespfau at gmail.com> 2012-12-16 08:24:13 PST ---
(In reply to comment #3)
> I'm not sure that this isn't just a GDC bug. Why should status necessarily be
> thread-local?

Maybe my conclusions were premature, but according to TDPL chapter 13.12.1 page
414: "The compiler optimizes code using non-shared data to the maximum, in full
confidence that no other thread can ever access it, and only tiptoes around
shared data".

The status field is not TLS data as it's not a static field, but it's instance
data and to my understanding if the class instance isn't marked as shared and
the field isn't shared the compiler is allowed to assume that only one thread
can access that data.

And if the compiler assumes status can only be accessed from one thread and
"atomicReadUbyte" is inferred as pure, that would lead to this wrong behavior.

You've got a point that this can't work for __gshared, so I'm not really sure
what to do about this.

So is it always invalid to optimize this code in D?
---------------------------------------
pure bool checkFlag(const ref bool a)
{

}

class A
{
    bool flag;

    void test()
    {
        while(true)
        {
            if(checkFlag(flag)) //Can this check be moved out of the loop
                return;
        }
    }
}
--------------------------------------

(In reply to comment #2)
> 
> I don't think the use of volatile statements/variables may help here...

wouldn't status as a volatile field signal to the compiler that it's value
might change between calls to "atomicReadUbyte" and therefore prevent this
optimization?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------