Scoped variables

[Doug Lea]

On 12/7/18 1:15 PM, dean.long at oracle.com wrote:
> Now might be a good time to start a discussion on how we want scoped
> variables to be created and named. 

Or backing up further, how about a discussion of use cases that should
be covered?

The simplest are cases maintaining a set of bindings that should be
captured by value and implicitly added as arguments for actions running
in (fiber) tasks. This could be seen as an extension to lambda
capture/binding (and in some cases could even be expressed by using
lambdas as arguments in task/fiber/thread constructors, without any
further support). They are also more similar to InheritableThreadLocal
than the plain kind.

At the other extreme are usages in which variables are split for the
sake of avoiding parallel update contention (but sometimes subject to
some form of parallel reduction). These seem out of scope(!) here.

Everything in between seems potentially controversial, so it would be
useful to focus on some canonical usages that should vs shouldn't be
targeted. Browsing through StackOverflow about issues with ThreadLocals
that might go away with other kinds of scoped constructs, it's hard to
make a conclusion. Most seem to tied to the use of frameworks (e.g.,
Spring) with forms of component contexts that initially assumed
single-threadedness and then adopted particular usage idioms with
ThreadLocals to allow restricted forms of multithreading. I don't know
if there are any exploitable commonalities across these, but others might?

-Doug