On Sat, 19 Mar 2011 13:09:23 -0400, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2011-03-19 12:03:51 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> 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.
Technically, you'd only need a shared delegate or a const delegate to
guarantee race safety for parallel foreach.
