Encounter order

[Paul Sandoz]

On Oct 23, 2012, at 10:45 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:

> OK, let me try this a different way.
> 
> Let's separate *result* from *side effects*.  Parallelism can change the timing of side-effects, but (I argue) should not change the result of a computation (e.g., summing integers in parallel should yield the same result as summing them sequentially (modulo overflow.))  

Agreed. 

The details of the parallelism should be abstracted from the developer. The act of parallelism should for the most part be an implementation detail that may or may not be applied depending on the problem and resources at hand.

Guy's talk is very relevant:

http://www.infoq.com/presentations/Thinking-Parallel-Programming

Especially slides 36-47 and the last 5 minutes of the talk.

As Guy says this has costs and overheads just as garbage collectors do but those costs are considered acceptable because they free the developer to focus on what is important for solving their problem.

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20121024/04932f0a/attachment.html