Something needs to happen with shared, and soon.

[Manu]

On 15 November 2012 04:30, Andrei Alexandrescu <
SeeWebsiteForEmail at erdani.org> wrote:

> On 11/11/12 6:30 PM, Walter Bright wrote:
>
>> 1. ensure single threaded access by aquiring a mutex
>> 2. cast away shared
>> 3. operate on the data
>> 4. cast back to shared
>> 5. release the mutex
>>
>
> This is very different from how I view we should do things (and how we
> actually agreed to do things and how I wrote in TDPL).
>
> I can't believe I need to restart this on a cold cache.


The pattern Walter describes is primitive and useful, I'd like to see
shared assist to that end (see my previous post).
You can endeavour to do any other fancy stuff you like, but until some
distant future when it's actually done, then proven and well supported,
I'll keep doing this.

Not to repeat my prev post... but in reply to Walter's take on it, it would
be interesting if 'shared' just added implicit lock()/unlock() methods to
do the mutex acquisition and then remove the cast requirement, but have the
language runtime assert that the object is locked whenever it is accessed
(this guarantees the safety in a more useful way, the casts are really
annying). I can't imagine a simpler and more immediately useful solution.

In fact, it's a reasonably small step to this being possible with
user-defined attributes. Although attributes have no current mechanism to
add a mutex, and lock/unlock methods to the object being attributed (like
is possible in Java/C#), but maybe it's not a huge leap.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121115/3aa2f74f/attachment.html>