review of std.parallelism

[Robert Jacques]

On Sat, 19 Mar 2011 13:09:23 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2011-03-19 12:03:51 -0400, Andrei Alexandrescu  
> <SeeWebsiteForEmail at 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.