Concurrency.

[Timon Gehr]

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.