What are the real advantages that D offers in multithreading?

[Thiez via Digitalmars-d]

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.