TDPL goes out for preliminary review

[Graham St Jack]

On Thu, 17 Dec 2009 03:04:59 +0000, Graham St Jack wrote:

> On Thu, 17 Dec 2009 01:13:36 +0100, grauzone wrote:
> 
>> Andrei Alexandrescu wrote:
>>> But let's not forget we have concurrency ahead of us. I encourage you
>>> all to chime in with your thoughts and ideas regarding all aspects of
>>> concurrency. The recent multicore performance bug is a great starting
>>> point. If you try e.g. shared and it's broken, let us know. If you try
>>> it and it works, push it til it breaks. If you have ideas on how to
>>> make semantic checking better, pipe up.
>> 
>> There's a guy on the NG who posts once in a while how broken shared is
>> and how he has to use __gshared instead. His threads are being pretty
>> much ignored.
>> 
>> And now?
>> 
>> 
>>> Andrei
> 
> I'm certainly in that category. I will be trying (soon) to put a post
> together that sets out my issues with 'shared'.

Here is my attempt to set out my problems with the "shared" keyword as it 
now stands.


First the good part: writing multi-threaded programs is not easy, and 
anything the language and compiler can do to make it easier is good.

Now for the way I approach writing multi-threaded programs:

Keep threads apart from each other wherever possible. Specifically, don't 
let them access or modify the same data except in well-understood and 
carefully controlled ways.

My preferred way of doing this is for threads to share only a very small 
amount of data, all of which is mutex protected, and carefully designed 
to be safe to access by multiple threads. My favourite kind of these is a 
templated queue (like a "go" channel). Any data passed out from such a 
"shareable object" has to be either immutable or cloned, so that each 
thread can rely on its data not being trampled on by other threads.

And my wish-list:

What I would like is for D to provide a clean way for me to be able to 
say "this object and all its methods are nice and safe to access from 
multiple threads", and to also say "all instances of this type are 
immutable".

And I also want the compiler to tell me if it thinks I have multiple 
threads accessing data in an unsafe way. 


Finally my issues with D as it stands:

Immutable or const objects are a real pain because I can't have a mutable 
reference to them. Rebindable doesn't seem to work, and I haven't been 
able to make a version that works well enough.

Immutable types don't add any value because you have to keep stating that 
objects of them are immutable everywhere. Having first-class immutable 
types would make it MUCH easier to reap the benefits of immutable data.

I can't currently see a use for the shared keyword as it stands. It seems 
to me that what is needed is a keyword more like "shareable", meaning 
that this object (or data or function?) can be safely accessed by 
multiple threads. It should be an error to access a non-shareable object 
with multiple threads.

It should also be an error to claim that something is shareable unless it 
meets some well thought out criteria that the compiler can check. I 
haven't thought these out yet, but some candidates I like the look of are:
* All outputs from the object must be immutable or passed by value 
(cloned).
* All externally accessible methods must be synchronized on the object's 
monitor.

I'm happy that some sort of back-door override like __gshared has to be 
there for those cases that are actually ok, but only because of some 
grubby detail that the compiler can't figure out.