What are the real advantages that D offers in multithreading?

Russel Winder via Digitalmars-d digitalmars-d at puremagic.com
Thu Feb 4 23:57:59 PST 2016


On Thu, 2016-01-28 at 22:38 +0000, nbro via Digitalmars-d wrote:
> 
[…]
> 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?

<Also hopefully fulfilling cym13's request for more detail.>

If a programming language imposes the overhead of concurrency
management on all and every thing involved, then you have a huge
overhead – even if it is not used, or even known about.

In the Java context, the whole object lock, wait, notify, notifyAll was
well intentioned in 1992–1995, but in hindsight was the wrong thing to
do. But to then impose monitor overhead (synchronized keyword on
methods) and to use it in the standard library everywhere, cf.
StringBuffer vs. StringBuilder, was rather silly. Hence the whole sad
history of the Java collections library, and it's somewhat farcical
iterators.

Thiez nicely summarized the next level of detail about the problems
with the Java object lock system, so I will avoid repeating that here.
The summary is that the standard Java object locks system is
fundamentally flawed, and should not be used. Sadly it is going to be
impossible to ever get away from it being part of the Java Platform.

So what is the way forward. This is many-fold:

1. Study the java.util.concurrent package set and use the concurrent
data structures available.

2. Study the java.util.concurrent package set and note the existence of
threadpools. Use asynchronous calls and futures. Use thread safe queues
to communicate and coordinate.

3. Use higher level abstractions such as actors, dataflow, CSP
(concurrent sequential process), active object, picoservices, etc. to
structure your code so as to avoid any an all explicit threads and
locks. Look at Akka, Quasar, GPars, for example frameworks.

Only people writing operating systems (or OS level "applications",
usually embedded systems on very constrained devices) should ever need
to worry about stack management, thread managment, etc. Everyone else
should be using higher-level abstractions built over the
infrastructure. Programming is about abstraction. Threads, language
stacks, etc. are the wrong abstraction level for almost all
applications programming, and most system programming.

The single biggest lesson that Go has brought front and centre (not
center, obviously) is that collections of sequential processes
communicating using channels is a very successful and easy to program
way of building extremely concurrent and parallel systems. Of course
this is something the HPC people have known for 35+ years since they
never got sidetracked by shared memory multithreading as a programming
architecture.

Shared memory multithreading is an operating systems architecture,
developed for writing operating systems. There is no reason why we
should continue to thing of the concurrency and parallelism theory of
operating systems as the one and only way of programming applications.

Whatever the 1990s and 2000s have said on architecting applications,
the 1960s model of actors, 1970s model of dataflow, and 1980s model of
CSP are far better architectural models for creating highly concurrent
and parallel applications and systems programs. 
   
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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


More information about the Digitalmars-d mailing list