Something needs to happen with shared, and soon.
Michel Fortin
michel.fortin at michelf.ca
Wed Nov 14 04:42:12 PST 2012
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. Use a struct to encapsulate the state,
then make bar, and baz member functions of that struct. The resulting
code is cleaner and easier to read:
pure int foo() {
auto state = State(new_value);
state.bar();
return state.baz();
}
You could achieve something similar with nested functions too.
> Unfortunately, this destroys 'pure' even though it actually does not.
Using a local-scoped struct would work with pure, be more efficient
(accessing thread-local variables takes more cycles), and be less
error-prone while refactoring.
--
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca/
More information about the Digitalmars-d
mailing list