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

[d-bugmail at puremagic.com]

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

           Summary: std.parallelism broken with extensive optimizations
                    (gdc)
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: critical
          Priority: P2
         Component: Phobos
        AssignedTo: nobody at puremagic.com
        ReportedBy: johannespfau at gmail.com


--- Comment #0 from Johannes Pfau <johannespfau at gmail.com> 2012-12-16 01:23:23 PST ---
Disclaimer: Although the title contains "gdc" this is not a gdc bug as far as I
can see. DMDs optimizer is probably not good enough to reproduce this bug
though. I guess ldc will also be affected.


Artem Tarasov recently filed a big on the gdc bugtracker about std.parallelism
randomly failing: http://gdcproject.org/bugzilla/show_bug.cgi?id=16

jerro added an example which always fails for him and added some comments:
----------------------------
import std.stdio, std.parallelism;

void main()
{
    writeln(taskPool.reduce!"a+b"([0, 1, 2, 3]));
}
----------------------------
"The reason for this is that gdc generates code that doesn't call
atomicReadUbyte(status) on every iteration of the loop in
std.parallelism.TaskPool.workLoop as the source code does, but calls it once
before the loop begins and then uses a stored value inside the loop."

And as far as I can see this is std.parallelisms fault (or you could also blame
it on the language for not having "volatile"):

workLoop repeatedly calls atomicReadUbyte(status). status is a member of
TaskPool with type ubyte. It's not marked as shared or volatile, but it's
_used_ as a shared variable. atomicReadUbyte also doesn't mark its parameter as
shared/volatile.

The GCC backend only sees a repeated access to a thread-local variable. It
can't know that the variable can be changed by different threads and obviously
optimizes the repeated function call away. It's the textbook example of
volatile.

The solution is probably not that obvious. There have been discussions whether
shared/__gshared should imply volatile, but as long as there is no official
statement in this regard, there's not much we can do.

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