You are correct, you'd use them to implement your own concurrent data structures per requirements. But I do think they're slightly higher level primitives than most languages provide, and there is some nice flexibility in the options available, in terms of control over sharing/mutability and mechanism.

RWArc allows multiple writers, but each blocks until the "active" writer gives up its lock. But I suppose you mean that you can't have concurrent writes, so I understand this might not be suitable for the use-cases you were talking about.

I think the Rust people have made the right choice at every juncture given the language requirements. It's a very impressive language, but it, too, has its sweet spots. There's a reason why Java has attracted so much concurrency research in the past decade, and why it's usually years ahead of almost any other platform in that respect: no, it's not (just) the platform-agnostic memory model, which later inspired C++11's (heck, it was done by the same people), but its world-class garbage collector(s). While it's possible to implement lock-free data structures without a good GC (with RCU), it's very difficult to do so in a general enough manner while still staying efficient. Java's GC, along with its memory model and direct access to CPU concurrency primitives (CASes since Java 5 and fences since Java 8), combined with Doug Lea's inspired implementations[1], have made the JVM the premier choice for anyone who wants to take advantage of cutting-edge concurrency.

[1]: http://www.youtube.com/watch?v=sq0MX3fHkro

EDIT: The Doug Lea talk linked above is probably the best overview of what doing low-level concurrency on modern hardware entails. In particular, it demonstrates interactions among abstractions layers and dispels myths that claim that having less software layers is always better (hardware already has so many layers as it is, that some software layers can actually help, if only to hide the hardware's complexity).

Thanks for the link to the Doug Lea screencast/talk, very interesting so far.

EDIT: Indeed it was a great talk, very informative! I came to the opposite conclusion about layers of the system, though I'd say that it isn't the number of layers that's the problem, but the nature of them.

From the talk, having the GC insert safepoints where threads can be stopped for a collection, and having the JIT inserting counters (resulting in memory contention) are two things in Java that caused for high-performance concurrency. Running on top of a VM causes similar issues. Though, clearly there are many other layers and unanticipated layer interactions, just laying in wait to mess you up regardless.

Well, he only mentions how these things make his life difficult, not how they make it easier. When you consider something, you must also consider the alternatives: a GC does insert safepoints on the one hand, but it makes lock-free data structures possible (or much, much easier) on the other. The JIT counters introduce contention before optimization kicks in, but then you get virtual method inlining, the mother of all optimizations, which you can't do without a JIT, certainly not when you want to support hot code loading.

Those things are necessary for the class of programs Java SE is meant to support (long running, high-performance server-side applications); they're not ideal for device drivers, command line programs or fast-loading GUI apps, which Rust is designed to handle. Everything is a tradeoff.

No, RWArc definitely allows more than one writer. One writer at a time, sure, but you can have multiple tasks try to write to it at the same time and the first will get access while the others will block.

EDIT: Oh, I see what you mean now; sorry, I misinterpreted. Carry on.