The "no gc" crowd

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Oct 10 19:43:40 PDT 2013


On 10/10/13 7:37 PM, Michel Fortin wrote:
> On 2013-10-11 02:08:02 +0000, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> said:
>
>> On 10/10/13 7:04 PM, Jonathan M Davis wrote:
>>> On Thursday, October 10, 2013 18:21:52 Andrei Alexandrescu wrote:
>>>> You can't EVER expect to obtain all of that magic by plastering
>>>> "shared"
>>>> on top of your type.
>>>
>>> It works just fine with the idiom that I described where you protect
>>> the usage
>>> of the object with a lock, cast it to thread-local to do stuff on it,
>>> and then
>>> release the lock (making sure that no thread-local references remain).
>>
>> TDPL describes how synchronized automatically peels off the "shared"
>> off of direct members of the object. Unfortunately that feature is not
>> yet implemented.
>
> That "direct member" limitation makes the feature pretty much worthless.
> It's rare you want to protect a single integer behind a mutex, generally
> you protect data structures like arrays or trees, and those always have
> indirections.

It's not about a single integer, it's about multiple flat objects. True, 
many cases do involve indirections.

> You could loosen it up a bit by allowing pure functions to use the
> member. But you must then make sure those functions won't escape a
> pointer to the protected structure through one of its argument, or the
> return value. That won't work with something like std.range.front on an
> array.
>
> Anyway, that whole concept of synchronized class is a deadlock honeypot.
> It should be scrapped altogether.

People still use it.


Andrei



More information about the Digitalmars-d mailing list