Does D have equivalent of Java util.concurrent?

[Russel Winder]

On Sun, 2019-04-28 at 08:40 +0000, Dibyendu Majumdar via Digitalmars-d wrote:
> 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.

I am sure we can have endless debates on the history of concurrency and
parallelism in Java, threads, JSR166, memory model, what came when, etc. and
what is now in java.util.concurrent. Whilst I was present all the way through
it, memory of history is never exact. And of course, in this context, it is
irrelevant. What matters is that D is missing something that means
std.concurrency and std.parallelism need review and integration, and possibly
extension. 
 
> > 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.

Java's Fork/Join Framework (based on Doug Lea's work) does indeed do work
stealing. If I remember correctly the threadpool in std.parallelism also
implements work stealing, which is why the threadpool needs to be opaque.
However, std.parallelism is not a system analogous to Fork/Join. Fork/Join is
a concurrency/parallelism architecture that D doesn't have support for. Hence
some people are looking to a port of java.util.concurrency and various other
bits. I believe this will replicate a lot of what is in std.parallelism. 

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

As far as I am aware only a few of the concurrent data structures in the Java
standard library are fully lock free. I could be wrong though, I haven't used
things from java.util.concurrent in a long while. 

[…]
> 
> 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.
> 

I am not an expert in the D data structures, but there are some on this list
who are. Having said that, in general, accessing data across threads generally
requires some form of overhead. This is part of why Go obsesses over sharing
data by sending it over channels. 

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20190522/f1c49c1c/attachment.sig>