January 28, 2016
On Tue, 2016-01-26 at 11:44 +0000, nbro via Digitalmars-d wrote:
> 
[…]
> Moreover, could you also explain why D was designed to synchronize entire classes instead of single methods. If I synchronize single methods (in Java for example), I could still be able to use other non-synchronized methods without needing to acquire the lock, so I don't understand this decision.

It should be pointed out that anyone using the synchronized keyword anywhere in Java code is doing concurrent and parallel programming wrong. If they are using synchronized in single threaded programming well, then…

The issue here is Java monitors, which are massively overweight, and have been since 1994. Indeed the whole wait/notify system is a serious problem. Sadly it took 20 years for people at the heart of Java development to finally admit this in (semi-)public. Doug Lea's, Brian Goetz, and others have over the last 10 years been making things better. A lot better.

So good concurrent and parallel Java eshews synchronized, wait and notify, and employs one or more of the thread safe parallel data structure, e.g. ConcurrentHashMap, the futures related things, or more usually now Streams.

synchronized, wait and notify along with the lock and monitors should be deprecated and removed.

Sadly as we know nothing that is deprecated ever gets removed from Java.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



January 28, 2016
On Wed, 27 Jan 2016 17:30:28 +0000, Brad Anderson wrote:

> Yeah, boost can do fibers. ASIO has clever/hacky "stackless coroutines" and C++17 is going to add "stackless resumable functions" for async/await. D is about to lose a competitive advantage here.

I looked at those stackless coroutines. They're nowhere near good enough for what I wanted to do. You can't use them for a vibe-like framework. But they're still called coroutines, so D's going to lose a marketing advantage.
January 28, 2016
On Thursday, 28 January 2016 at 10:26:29 UTC, Kagamin wrote:
> On Wednesday, 27 January 2016 at 17:30:28 UTC, Brad Anderson wrote:
>> Yeah, boost can do fibers. ASIO has clever/hacky "stackless coroutines" and C++17 is going to add "stackless resumable functions" for async/await. D is about to lose a competitive advantage here.
>
> Isn't asio based on fibers just like vibe?

More like generators, like C#, Hack or python. Note that the 2 strategies can be used concurrently. For instance, HHVM run each request in a fiber + use asio within request to get another level of parallelism.

January 28, 2016
On Thursday, 28 January 2016 at 10:26:29 UTC, Kagamin wrote:
> On Wednesday, 27 January 2016 at 17:30:28 UTC, Brad Anderson wrote:
>> Yeah, boost can do fibers. ASIO has clever/hacky "stackless coroutines" and C++17 is going to add "stackless resumable functions" for async/await. D is about to lose a competitive advantage here.
>
> Isn't asio based on fibers just like vibe?

No, it's primarily a callback oriented interface. Boost.Fiber (which is relatively new) added some stuff so you could use something more like vibe.d with ASIO. ASIO has had a "stackless coroutine" option since 1.42, I think. They are, like I said, very clever and hacky. It uses preprocessor macros to define new "keywords". They use switches and loops under the hood to appears as coroutines[1]. It's an impressive idea but language supported coroutines would be a lot better.

ASIO is serving as the basis for C++17's network library. The co-routines are still being argued about but if the design gets nailed down before then I'm sure the C++17 networking library will make use of the feature.

1. http://www.boost.org/doc/libs/1_56_0/boost/asio/coroutine.hpp
January 28, 2016
On Thursday, 28 January 2016 at 17:21:21 UTC, Chris Wright wrote:
> On Wed, 27 Jan 2016 17:30:28 +0000, Brad Anderson wrote:
>
>> Yeah, boost can do fibers. ASIO has clever/hacky "stackless coroutines" and C++17 is going to add "stackless resumable functions" for async/await. D is about to lose a competitive advantage here.
>
> I looked at those stackless coroutines. They're nowhere near good enough for what I wanted to do. You can't use them for a vibe-like framework. But they're still called coroutines, so D's going to lose a marketing advantage.

They aren't fit for every task, of course.

They've been discussed here on the NG in the past: http://forum.dlang.org/thread/izosaywbnlxnbzyhjbnu@forum.dlang.org
January 28, 2016
On Thursday, 28 January 2016 at 11:53:48 UTC, Russel Winder wrote:
> On Tue, 2016-01-26 at 11:44 +0000, nbro via Digitalmars-d wrote:

>
> It should be pointed out that anyone using the synchronized keyword anywhere in Java code is doing concurrent and parallel programming wrong. If they are using synchronized in single threaded programming well, then…
>
> The issue here is Java monitors, which are massively overweight, and have been since 1994. Indeed the whole wait/notify system is a serious problem. Sadly it took 20 years for people at the heart of Java development to finally admit this in (semi-)public. Doug Lea's, Brian Goetz, and others have over the last 10 years been making things better. A lot better.
>
> So good concurrent and parallel Java eshews synchronized, wait and notify, and employs one or more of the thread safe parallel data structure, e.g. ConcurrentHashMap, the futures related things, or more usually now Streams.
>
> synchronized, wait and notify along with the lock and monitors should be deprecated and removed.
>
> Sadly as we know nothing that is deprecated ever gets removed from Java.

I don't understand why you say that everyone that uses synchronized is doing bad concurrent programming. That's not correct, if you know how to use it. Also, I don't understand why also lock and monitors should be removed. How would you write then multithreaded programs?
January 28, 2016
On Tuesday, 26 January 2016 at 11:44:56 UTC, nbro wrote:
> On Tuesday, 26 January 2016 at 11:41:49 UTC, nbro wrote:
>> Hi!
>>
>> I have seen that D offers basically similar constructs to Java for example for creating multithreaded applications. I would like to understand better what are the real advantages that D offers. Does D offer something that other known programming languages, such as C++, Java and Python, do not offer? An exhaustive explanation with concrete examples would be nice.
>
> Moreover, could you also explain why D was designed to synchronize entire classes instead of single methods. If I synchronize single methods (in Java for example), I could still be able to use other non-synchronized methods without needing to acquire the lock, so I don't understand this decision.

I don't know what was the decisive point of the decision but in can't help but note that it makes a lot of sense because D has functions.

Object methods are meant to be used with the encapsulated data. If it doesn't touch those data then it must be a function, it has nothing to do as a method. If it does touch those data then in multithreaded applications synchronizing only one amongst others doesn't make any sense: encapsulated data is a share resource. In java you don't have functions, only methods, so I sort-of understand why they did it that way. But in any other (sane?) language functions should be decoupled from methods anyway.
January 28, 2016
On Thursday, 28 January 2016 at 11:53:48 UTC, Russel Winder wrote:
> It should be pointed out that anyone using the synchronized keyword anywhere in Java code is doing concurrent and parallel programming wrong. If they are using synchronized in single threaded programming well, then…
>
> [...]

I have seen you talk about this before and I too would love you to elaborate on the subject.
January 29, 2016
On Thursday, 28 January 2016 at 22:59:58 UTC, cym13 wrote:
> On Thursday, 28 January 2016 at 11:53:48 UTC, Russel Winder wrote:
>> It should be pointed out that anyone using the synchronized keyword anywhere in Java code is doing concurrent and parallel programming wrong. If they are using synchronized in single threaded programming well, then…
>>
>> [...]
>
> I have seen you talk about this before and I too would love you to elaborate on the subject.

One of the most obvious problems with using `synchronized` on methods, or using `synchronized(this)`, is that an object has no control over its monitor. All code that can see a particular instance can choose to synchronize on that instance, which creates opportunities for deadlocks. This problem can be avoided by controlling access to the monitor you use. One of the easiest ways to control access to your monitor is by having a private object to synchronize on (e.g. `private final Object lock = new Object();`) instead of synchronizing on `this`. Further improvements can be made by explicitly using one of the classes found in java.util.concurrent.locks: this allows you to be more explicit by, for instance, choosing a ReadWriteLock, and it provides access to proper conditions.

Another problem with `synchronized` in Java is that it requires all objects to contain an implicit monitor, while the vast majority of objects will never get synchronized on: for all those objects this is useless overhead. Sadly backwards compatibility implies that Java will likely never be able to entirely get rid of this overhead.
January 30, 2016
On Wednesday, 27 January 2016 at 09:33:16 UTC, Kagamin wrote:
> On Tuesday, 26 January 2016 at 20:33:34 UTC, Chris Wright wrote:
>> You can use fibers in C++ if you find a library to do it (boost might?). You might be able to find a Java library for it, but it's difficult and might require bytecode rewriting.
>
> The java approach is Netty and NIO.

Netty and NIO are an event dispatching mechanism (think libebevent) backed by a ForkJoinPool. No fibers there. Java /does/ have fibers in Quasar, though the implementation is a bit weird because the Java instruction set doesn't support continuations.

Message passing via std.concurrency is important to note. The scheduler is pluggable and can seamlessly multiplex fibers on top of a thread pool (the Erlang "millions of threads" approach). Thread local by default is notable as well, though fibers throw a wrench in this. The "synchronized" keyword is inadvisable in modern concurrent programming. I think it remains largely to ease porting code from Java.