http://gdcproject.org/bugzilla/show_bug.cgi?id=16

jerro.public@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jerro.public@gmail.com

--- Comment #1 from jerro.public@gmail.com 2012-12-16 04:47:21 UTC ---
I'm having a problem with this bug too, but for me the test case in the report only hangs in rare cases. This hangs every time for me (on x86_64 debian wheezy with commit f07f442 of GDC built with GCC 4.8-20121209):

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.

-- 
Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all issue changes.

http://gdcproject.org/bugzilla/show_bug.cgi?id=16

Johannes Pfau <johannespfau@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |johannespfau@gmail.com
         Resolution|                            |WONTFIX

--- Comment #2 from Johannes Pfau <johannespfau@gmail.com> 2012-12-16 09:14:38 UTC ---
Great. Remember the "we don't need volatile in D, it's dangerous" statements? This problem is caused by 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.

Anyway, it's a bug in std.parallelism, not in gdc so I'll file a bug report on the phobos bugzilla.

-- 
Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all issue changes.

http://gdcproject.org/bugzilla/show_bug.cgi?id=16

--- Comment #3 from Johannes Pfau <johannespfau@gmail.com> 2012-12-16 09:25:45 UTC ---
http://d.puremagic.com/issues/show_bug.cgi?id=9163

-- 
Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all issue changes.