Something needs to happen with shared, and soon.

Timon Gehr timon.gehr at gmx.ch
Wed Nov 14 02:30:46 PST 2012


On 11/14/2012 04:12 AM, Michel Fortin wrote:
> On 2012-11-13 19:54:32 +0000, Timon Gehr <timon.gehr at gmx.ch> said:
>
>> On 11/12/2012 02:48 AM, Michel Fortin wrote:
>>> I feel like the concurrency aspect of D2 was rushed in the haste of
>>> having it ready for TDPL. Shared, deadlock-prone synchronized classes[1]
>>> as well as destructors running in any thread (thanks GC!) plus a couple
>>> of other irritants makes the whole concurrency scheme completely flawed
>>> if you ask me. D2 needs a near complete overhaul on the concurrency
>>> front.
>>>
>>> I'm currently working on a big code base in C++. While I do miss D when
>>> it comes to working with templates as well as for its compilation speed
>>> and a few other things, I can't say I miss D much when it comes to
>>> anything touching concurrency.
>>>
>>> [1]: http://michelf.ca/blog/2012/mutex-synchonization-in-d/
>>
>> I am always irritated by shared-by-default static variables.
>
> I tend to have very little global state in my code,

So do I. A thread-local static variable does not imply global state. 
(The execution stack is static.) Eg. in a few cases it is sensible to 
use static variables as implicit arguments to avoid having to pass them 
around by copying them all over the execution stack.

private int x = 0;

int foo(){
     int xold = x;
     scope(exit) x = xold;
     x = new_value;
     bar(); // reads x
     return baz(); // reads x
}

Unfortunately, this destroys 'pure' even though it actually does not.

> so shared-by-default
> is not something I have to fight with very often.  I do agree that
> thread-local is a better default.
>




More information about the Digitalmars-d mailing list