Concurrency.

[Timon Gehr]

On 12/01/2011 04:51 PM, Timon Gehr wrote:
> On 12/01/2011 03:29 AM, Jonathan M Davis wrote:
>> On Wednesday, November 30, 2011 17:06:22 Sean Kelly wrote:
>>> On Nov 28, 2011, at 2:54 AM, Jonathan M Davis wrote:
>>>> On Monday, November 28, 2011 10:28:34 Debdatta wrote:
>>>>> Let me get this straight. Instances are shared... and marking a class
>>>>> shared marks all its members shared? If what you said were true, it
>>>>> would be trivial to instantiate a class as both shared and unshared.
>>>>> Without any duplication.
>>>>>
>>>>> class A
>>>>> {
>>>>> ///
>>>>> }
>>>>>
>>>>> shared A sharedA = new A;
>>>>> A unsharedA = new A;
>>>>>
>>>>> I don't can you elaborate your last post?
>>>>
>>>> Instantiating it isn't the hard part. You probably need a constructor
>>>> which is shared, but that's not all that big a deal. The problem is
>>>> that every member function that you want to call with a shared instance
>>>> needs to be marked as shared (just like a member function which is
>>>> called with a const instance must be marked as const). And while a
>>>> const member function may work with both mutable and immutable
>>>> instances, a shared member function will _only_ work with shared
>>>> instances.
>>>
>>> This seems wrong to me. If a function is callable in a shared
>>> scenario, why
>>> would it not be callable in an unshared scenario? At worst depending on
>>> how shared were implemented the call would be slower than an unshared
>>> version but still entirely correct.
>>
>> While it may be theoretically fine, as I understand it, that's how the
>> type
>> system operates at this point. However, I use shared quite rarely, so
>> some of
>> its finer points are likely to escape me. I definitely have to agree,
>> however,
>> that at this point, using shared heavily seems to be quite problematic
>> due to
>> stuff like seemingly unnecessary code duplication which is currently
>> necessary.
>>
>> - Jonathan M Davis
>
> You bring this up very often. Do you write a lot of concurrent code
> where this actually bothers you?
>
> Efficient shared methods need to be different from efficient unshared
> ones anyway.
>
> If it is just about having locked versions of some methods that perform
> the same operations (except they may randomly dead lock your program if
> you are not cautious), then, well: even languages that do not have the
> 'shared' type modifier use synchronized wrapper classes to solve *the
> same problem*. In D, the boilerplate that constitutes the wrapper class
> should even be able to be generated by some nifty little template. Or
> alternatively you just mix in the wrapper methods into the same class.
> This is impossible to achieve in other languages.
>

(I meant 'other languages that do not support the shared modifier', 
obviously)