[Issue 16] Programs that use std.parallelism.taskPool hang

[gdc-bugzilla at gdcproject.org]

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

Johannes Pfau <johannespfau at gmail.com> changed:

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

--- Comment #2 from Johannes Pfau <johannespfau at 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.