Java programmers have benefited hugely from Doug Lea's work (http://gee.cs.oswego.edu/dl/concurrency-interest/index.html). I was wondering if D's library has anything equivalent. If not, I am interested in porting Doug Lea's library from Java to D; I think the license allows this, but I will check with Doug Lea.

On Saturday, 27 April 2019 at 14:15:01 UTC, Dibyendu Majumdar wrote:
> Java programmers have benefited hugely from Doug Lea's work (http://gee.cs.oswego.edu/dl/concurrency-interest/index.html). I was wondering if D's library has anything equivalent. If not, I am interested in porting Doug Lea's library from Java to D; I think the license allows this, but I will check with Doug Lea.

I checked with Doug - the core concurrent library code at his site is in the public domain so it can be freely ported to another language.

On Saturday, 27 April 2019 at 14:15:01 UTC, Dibyendu Majumdar wrote:
> Java programmers have benefited hugely from Doug Lea's work (http://gee.cs.oswego.edu/dl/concurrency-interest/index.html). I was wondering if D's library has anything equivalent. If not, I am interested in porting Doug Lea's library from Java to D; I think the license allows this, but I will check with Doug Lea.

Concurrent features included in Phobos are nicely written down here

http://ddili.org/ders/d.en/concurrency.html
http://ddili.org/ders/d.en/parallelism.html
http://ddili.org/ders/d.en/concurrency_shared.html

You may have a look to see wheter there is an overlap and what is missing.

Kind regards
Andre

On Saturday, 27 April 2019 at 18:26:53 UTC, Andre Pany wrote:
> Concurrent features included in Phobos are nicely written down here
>
> http://ddili.org/ders/d.en/concurrency.html
> http://ddili.org/ders/d.en/parallelism.html
> http://ddili.org/ders/d.en/concurrency_shared.html
>

That's interesting, thanks.
I also found this: http://www.informit.com/articles/article.aspx?p=1609144


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.

On Saturday, 27 April 2019 at 14:15:01 UTC, Dibyendu Majumdar wrote:
> Java programmers have benefited hugely from Doug Lea's work (http://gee.cs.oswego.edu/dl/concurrency-interest/index.html). I was wondering if D's library has anything equivalent. If not, I am interested in porting Doug Lea's library from Java to D; I think the license allows this, but I will check with Doug Lea.

We have done somthing about this. See here:

Source: https://github.com/huntlabs/hunt/tree/master/source/hunt/concurrency
Examples: https://github.com/huntlabs/hunt/tree/master/examples/UnitTest/source/test

Current stage: We are trying to port the CompletableFuture.

On 28/04/2019 12:13 PM, Dibyendu Majumdar wrote:
> On Saturday, 27 April 2019 at 18:26:53 UTC, Andre Pany wrote:
>> Concurrent features included in Phobos are nicely written down here
>>
>> http://ddili.org/ders/d.en/concurrency.html
>> http://ddili.org/ders/d.en/parallelism.html
>> http://ddili.org/ders/d.en/concurrency_shared.html
>>
> 
> That's interesting, thanks.
> I also found this: http://www.informit.com/articles/article.aspx?p=1609144
> 
> 
> 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.

What model are you thinking it is imposing?

On Sun, 2019-04-28 at 00:13 +0000, Dibyendu Majumdar via Digitalmars-d wrote:
> On Saturday, 27 April 2019 at 18:26:53 UTC, Andre Pany wrote:
> > Concurrent features included in Phobos are nicely written down here
> > 
> > http://ddili.org/ders/d.en/concurrency.html http://ddili.org/ders/d.en/parallelism.html http://ddili.org/ders/d.en/concurrency_shared.html
> > 

std::parallelism uses a threadpool and tasks approach and provide parallelism features harmonious with the D programming model.

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.

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

-- 
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 Sunday, 28 April 2019 at 01:22:32 UTC, Heromyth wrote:
> On Saturday, 27 April 2019 at 14:15:01 UTC, Dibyendu Majumdar wrote:
>> Java programmers have benefited hugely from Doug Lea's work (http://gee.cs.oswego.edu/dl/concurrency-interest/index.html). I was wondering if D's library has anything equivalent. If not, I am interested in porting Doug Lea's library from Java to D; I think the license allows this, but I will check with Doug Lea.
>
> We have done somthing about this. See here:
>
> Source: https://github.com/huntlabs/hunt/tree/master/source/hunt/concurrency
> Examples: https://github.com/huntlabs/hunt/tree/master/examples/UnitTest/source/test
>
> Current stage: We are trying to port the CompletableFuture.

Nice. Some questions:

Have you based this on the Java8 version from Doug Lea's repository? Presumably this isn't a port of Oracle's version?
The concurrent collections aren't ported, am I right?

BTW Doug Lea's copyright notice should be retained in the sources if you have ported his code.

On Sunday, 28 April 2019 at 03:54:43 UTC, rikki cattermole wrote:
> On 28/04/2019 12:13 PM, Dibyendu Majumdar wrote:
>> On Saturday, 27 April 2019 at 18:26:53 UTC, Andre Pany wrote:
>>> Concurrent features included in Phobos are nicely written down here
>>>
>>> http://ddili.org/ders/d.en/concurrency.html
>>> http://ddili.org/ders/d.en/parallelism.html
>>> http://ddili.org/ders/d.en/concurrency_shared.html

>> 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.
>
> What model are you thinking it is imposing?

I have to understand the model. Suppose some mutable data is passed around between threads. I don't really know as I haven't read this in detail - but my question is this: is there a cost to accessing data across threads?

As in C or C++ I would expect the cost to be zero unless marked volatile.

I admit I don't understand the model of memory access in D. It seems that like Go, D is attempting to push a message passing model - that's what I meant by 'imposing a model'.

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.