On Saturday, 30 January 2016 at 17:46:35 UTC, Sean Kelly wrote:
> 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.

I mean approach to the same problem of handling of many requests, that fibers are used for in vibe.d.

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