Bartosz Milewski Missing post

[Bartosz Milewski]

Andrei Alexandrescu Wrote:

> BCS wrote:
> > Everything is indicating that shared memory multi-threading is where 
> > it's all going.
> 
> That is correct, just that it's 40 years late. Right now everything is 
> indicating that things are moving *away* from shared memory.
> 
> Andrei

I understand where you stand. You are looking at where the state-of-the-art hardware is going and that makes perfect sense. There is, however, a co-evolution of hardware and software that is not a simple software-follow-hardware (remember the era of RISC processors?). 

I'm looking at programming languages and I don't see that away-from-shared-memory trend--neither in mainstream languages, nor in newer languages like Scala, nor in the operating systems. There are many interesting high-level paradigms like message passing, futures, actors, etc.; and I'm sure there will be more in the future. D has a choice of betting the store on one of these paradigms (like ML did on message passing or Erlang on actors) or to try, build solid foundations for a multi-paradigm language or do nothing. I am trying to build the foundations.

The examples that I'm exploring in my posts are data structures that support higher level concurrency: channels, message queues, lock-free objects, etc. I want to build a system where high-level concurrency paradigms are reasonably easy to implement. 

Let's look at the alternatives. 

Nobody thinks seriously of making message passing a language feature in D. The Erlangization of D wouldn't work because D does not provide guarantees of address space separation (and providing such guarantees would cripple the language beyond repair). 

Another option we discussed was to provide specialized, well tested message queues in the library and count on programmers' discipline not to stray away from the message passing paradigm. Without type-system support, though, such queues would have to be either unsafe (no guarantee that the client doesn't have unprotected aliases to messages), or restrict messages to very simple data structures (pass-by-value and maybe some very clever unique pointer/array template). The latter approach introduces huge complexity into the library, essentially making user-defined extensions impossible (unless the user's name is Andrei ;-) ). 

Let's not forget that right now D is _designed_ to support shared-memory programming. Every D object has a lock, it supports synchronized methods, the keyword "shared" is being introduced, etc. It doesn't look like D is moving away from shared memory. It looks more like it's adding some window dressing to the pre-existing mess and bidding its time. I haven't seen a comprehensive plan for D to tackle concurrency and I'm afraid that if D doesn't take a solid stance right now, it will miss the train.