On 2011-03-19 12:03:51 -0400, Andrei Alexandrescu
<[email protected]> said:
* "Most of this module completely subverts..." Vague characterizations
("most", "completely", "some") don't belong in a technical
documentation. (For example there's either subversion going on or there
isn't.) Also, std.concurrency and std.parallelism address different
needs so there's little competition between them. Better: "Unless
explicitly marked as $(D @trusted) or $(D @safe), artifacts in this
module are not provably memory-safe and cannot be used with SafeD. If
used as documented, memory safety is guaranteed."
Actually, I think this is a bad description of what it subverts. What
it subverts isn't the memory-safety that SafeD provides, but the safety
against low-level races that even unsafe D protects against unless you
cast shared away. For instance:
void main() {
int sum = 0;
foreach (int value; taskPool.parallel([0,2,3,6,1,4,6,3,3,3,6]))
{
sum += value;
}
writeln(sum);
}
The "+=" would need to be an atomic operation to avoid low-level races.
I think that ParallelForeach's opApply should only accept a shared
delegate. I define shared delegate as a delegate that does not
reference any non-shared variables of its outer scope. The problem is
that DMD currently doesn't know how to determine whether a delegate
literal is shared or not, thus a delegate literal is never shared and
if ParallelForeach's opApply asked a shared delegate as it should it
would just not work. Fix DMD to create shared delegate literals where
appropriate and everything can be guarantied race-free.
--
Michel Fortin
[email protected]
http://michelf.com/
