review of std.parallelism

dsimcha dsimcha at yahoo.com
Sat Mar 19 12:36:24 PDT 2011


On 3/19/2011 2:35 PM, Michel Fortin wrote:
> On 2011-03-19 13:16:02 -0400, dsimcha <dsimcha at yahoo.com> said:
>
>>> * "A goto from inside the parallel foreach loop to a label outside the
>>> loop will result in undefined behavior." Would this be a bug in dmd?
>>
>> No, it's because a goto of this form has no reasonable, useful
>> semantics. I should probably mention in the docs that the same applies
>> to labeled break and continue.
>>
>> I have no idea what semantics these should have, and even if I did,
>> given the long odds that even one person would actually need them, I
>> think they'd be more trouble than they're worth to implement. For
>> example, once you break out of a parallel foreach loop to some
>> arbitrary address (and different threads can goto different labels,
>> etc.), well, it's no longer a parallel foreach loop. It's just a bunch
>> of completely unstructured threading doing god-knows-what.
>>
>> Therefore, I slapped undefined behavior on it as a big sign that says,
>> "Just don't do it." This also has the advantage that, if anyone ever
>> thinks of any good, clearly useful semantics, these will be
>> implementable without breaking code later.
>
> I think an improvement over undefined behaviour would be to throw an
> exception.

The only problem is that there's no easy, well-documented way to tell 
from the return value of opApply whether it was a break, a goto, a 
labeled break/continue, etc.  This would be implementable only if I 
changed the semantics of break to also throw.  This might not be a bad 
thing (IMHO any type of breaking out of a parallel foreach loop is just 
silly) but others had asked for different semantics for break.

>
> Also, what happens if one of the tasks throws an exception?
>

It gets rethrown when yieldWait()/spinWait()/workWait() is called.  In 
the case of the higher-level primitives, it gets re-thrown to the 
calling thread at some non-deterministic point in the execution of these 
functions.  I didn't see the need to document this explicitly because it 
"just works".



More information about the Digitalmars-d mailing list