Something needs to happen with shared, and soon.

[Timon Gehr]

On 11/14/2012 01:42 PM, Michel Fortin wrote:
> On 2012-11-14 10:30:46 +0000, Timon Gehr <timon.gehr at gmx.ch> said:
>
>> 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
>> }
>
> I'd consider that poor style.

I'd consider this a poor statement to make. Universally quantified 
assertions require more rigorous justification.

"In a few cases" it is not, even if it is poor style "most of the time".

> Use a struct to encapsulate the state, then make bar, and baz member functions of that struct.

They could eg. be virtual member functions of a class already.

> Using a local-scoped struct would work with pure,

It might.

> be more efficient

Not necessarily.

> (accessing thread-local variables takes more cycles),

It can be accessed sparsely, copying around the struct pointer is work 
too, and the fastest access path in a proper alternative design would 
potentially be even slower.

> and be less error-prone while refactoring.

If done in such a way that it makes refactoring error prone, it is to be 
considered poor style.