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

On Sun, 2019-04-28 at 09:21 +0000, Dibyendu Majumdar via Digitalmars-d wrote:
> 
[…]
> I wasn't talking about the cost of passing data, more about the cost of operations with this.
> 
> Say we have something like this.
> 
> 
> SomeFunc(data)
>      various ops with data
>      return data
> 
> There should not be any extra overhead in the 'ops' part above. In C++ if data was marked volatile, then there would be an impact, but not otherwise, apart from the standard optimisation rules to do with data escaping, or aliasing something.

In a single threaded context this is entirely right. In a multi-threaded context then it is very likely that the "various ops with data" would be wrapped with a std::mutex or similar. The overhead is before and after the "various ops with data", the ops themselves should not have any overhead.

-- 
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