Next best to what? At one extreme you have total languages such as agda and epigram, which can even the halting problem through dependent typing and by virtue of not being Turing complete.
On the other extreme you have raw assembly language, where anything goes.
Then there's a wealth of languages and frameworks in between that offer varying solutions to parallel programming: Clojure, Haskell, Scala, F#, Scheme, Groovy, Erlang, Fortress, Chapel, X10, so on and so forth
On this spectrum, Java really is not the "next best option". it falls somewhere between assembly and *every single other language* I listed above. It's not even the next best option on the JVM platform.
On 20 August[masked]:52, Jack Shirazi <[address removed]>
It's been bugging me for quite a few years, and I came to the conclusion
the only way to do it easily is with a language that makes it impossible
to write race conditions. If you know of one that isn't too esoteric,
I'd be interested. Otherwise, we're stuck with Java as the next best option.
On 20/08/[masked]:36, Ben Evans wrote:
> People always seem to be interested in hearing about concurrency.
> This post from Doug Lea is an excellent summary of how to approach
> concurrent programming, and I thought the group might be interested in
> discussing it.
> ---------- Forwarded message ----------
> From: Doug Lea <[address removed]>
> Date: Thu, Aug 16, 2012 at 11:25 AM
> Subject: Re: [concurrency-interest] Double Checked Locking in OpenJDK
> To: [address removed]
> On 08/16/12 02:10, Zhong Yu wrote:
>> We are probably discussing two very different types of programs that require
>> different considerations:
> There are *many* cases, some of which have more efficient solutions
> than others. You are not likely to find too many simple slogans
> 1. When possible, use design patterns that allow
> java.util.concurrent (and/or other libraries/frameworks) to do
> all the work for you in ensuring correctness and efficiency
> without you dealing with it at all. (Simple examples include
> Producer/Consumers and registries based on ConcurrentHashMaps.)
> 2. Otherwise, when possible, keep objects/data isolated within
> 3. Otherwise, when possible, stay within the bounds of simple
> idioms including: final fields for immutable data; AtomicX's
> (with compareAndSet) for reliably updatable single variables,
> latches/phasers for barriers, etc.
> 4. Use locks (either library-based or builtin) for most
> everything else.
> There are and always will be cases that fall outside these.
> Concurrent/parallel programming is at least as diverse as
> any other aspect of programming, and just about any
> style/approach can be made to work great, although some
> with a lot more care and opportunity for error than others.
>> On Wed, Aug 15, 2012 at 11:44 PM, Boehm, Hans<[address removed]> wrote:
>>> This doesn't mean that synchronization to avoid data races is entirely
>>> free, but only that it's cost doesn't increase, and often decreases with
>>> scale. Doug may well have run more careful experiments around this.
> Right; see above. It's hard to generalize beyond the observation
> that, with sufficiently fine-grained control, sync is rarely the
> main bottleneck, mainly because efficient combinations of immutability,
> publication idioms, CAS, blocking sync, etc become available.
> But that over-reliance on coarse-grained locking is a common
> performance/scalability problem in Java programs.