On Thursday, September 15, 2011 11:17:43 AM UTC-4, Josh Berry wrote: > Just lifting the variable to a field means you have completely moved > the memory semantics of it. Suddenly "volatile" is a relevant > modifier of a local variable. Well, some of them. :) (Right?) > The current language does not allow 'volatile' for local variables; so lifting a local variable to a non-volatile field (the most straightforward implementation) would not have any JMM consequences. But that's the point where Oracle claims that mutable capture is bad, because the programmer could possibly use the closure in multithreaded code and then we need to worry about JMM. My preferred solution is just allowing 'volatile' as a modifier for all locals; if you use that on a non-captured local, then the modifier is ignored, but if you use it on a local that's captured by a closure, then it's lifted to a volatile field. This solution is orthogonal: no special case for captured vs. non-captured, the non-captured case is an optimization because it is visible to a single thread so it behaves like a volatile field without needing any memory barriers. And this solution allows you to solve concurrent programming issues just like you'd do for equivalent code without closures; the captured local would be explicitly marked as volatile and then it's up to you to use it correctly. I would concede to have a default javac warning for mutable locals that are closure-captured but lack the 'volatile' modifier; this should be good enough to make closures very friendly to concurrent programming, even at the expense of needing an annoying @SuppressWarning annotation for the cases where volatile is not necessary because the closure will only be invoked in the same thread of its instantiation (it wouldn't be hard for javac to detect some of these cases - just do escape analysis at the javac level - then the warning could be automatically suppressed).
A+ Osvaldo -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/18QQ8ztGs1EJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
