capturing (or not) mutable local variables

Doug Lea dl at cs.oswego.edu
Sat Nov 27 10:36:16 PST 2010


On 11/27/10 06:54, Stephen Colebourne wrote:
> While I can entirely see why the mutable variable restriction is
> desirable from a correctness POV, I'm far from convinced that it is
> beneficial from a practical POV.

When those of us writing underlying core library support cannot
rely on locality properties, it means that all the application
code that uses it is also suspect, which might be a practical problem :-)

>
> (Note that it could be argued based on the above, that mutable access
> via arrays should be blocked to force an object based workaround like
> AtomicRefs)

Mostly as an aside: While the borderlines are fuzzy,
concurrent programming is mainly about synchronization, and
parallel programming is mainly about isolation.

AtomicRefs and the like should be rarely applicable
in constructions oriented toward parallel execution.
As I mentioned, annotations causing translation
into ThreadLocals seems plausible for scalars, but for
arrays you'd probably prefer some sort of wrapper
that causes the program to blow up if any element
is ever accessed by any thread other than its creator.

-Doug


More information about the lambda-dev mailing list