Does D have equivalent of Java util.concurrent?

[Dibyendu Majumdar]

On Sunday, 28 April 2019 at 08:05:48 UTC, Russel Winder wrote:

> The ForkJoin model at the heart of Doug's (and lots of other 
> people now) framework is not the only concurrency and 
> parallelism tool in JDK, Streams make use of the framework 
> underneath but they provide a lot that has nothing to do with 
> the framework.

That's not true - it isn't the heart of the concurrency library - 
in fact it came later.

>
> It could be argued that there is nothing in the JDK that cannot 
> already be done in D, that there is no point in porting the 
> ForkJoin framework to D since it would provide no new facility, 
> that everything the port of ForkJoin would offer is already 
> available in D.
>

I have not used the ForkJoin framework much - so I don't know 
what benefits it may or may not have over D's threadpool. I read 
it has something called work stealing but that's the limit of my 
knowledge about that.

The main advantages of Java's library are lock free / concurrent 
data structures and synchronisation methods that are high 
performance.

>> 
> […]
>> 
>> I need to understand the model used by D. As a systems 
>> language it should not be imposing a programming model but it 
>> appears to do so here.
>
> I do not understand this final sentence. All programming 
> language from assembly language, C, C++, D, Rust, Go (all of 
> which claim to be systems programming languages) provide a 
> programming model.

My question is: is there a cost to accessing data across threads? 
The document I was reading (from Andrei's book) appeared to imply 
there is. I would expect the cost to be zero unless some data was 
marked volatile as in C or C++. Maybe I misunderstood and this is 
the case.