RFC: naming for FrontTransversal and Transversal ranges

[Denis Koroskin]

On Sat, 02 May 2009 18:17:16 +0400, Denis Koroskin <2korden at gmail.com> wrote:

> On Sat, 02 May 2009 18:08:30 +0400, Andrei Alexandrescu  
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> Robert Jacques wrote:
>>> On Sat, 02 May 2009 03:35:51 -0400, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>>> Robert Jacques wrote:
>>>>>> No, repeated allocations are trivial to eliminate. I didn't even
>>>>>> bother to explain that in the article. The loop must only refill the
>>>>>> allocated object from the object that needs to be replaced.
>>>>>  putting the test in the pseudo code for this would've help my
>>>>> understanding.
>>>>>  if(copy is null)
>>>>>     copy = s.deepDup;
>>>>> else
>>>>>     s.deepDupTo(copy);
>>>>
>>>> copy = cast(T*) GC.malloc(T.sizeof);
>>>> do {
>>>>      overwrite(s, copy);
>>>>      copy.modify;
>>>> } while (!cas(copy, s));
>>>  I'm confused. The article talks about copying the entire data
>>> structure, not just a node/etc. And trees, etc tend to have variable
>>> sizes, etc.
>>
>> You can reuse memory even if it comprehends more complex patterns than
>> one single allocation.
>>
>> Andrei
>
> I *highly* doubt it is worth the trouble. Most likely, this container  
> won't be lock-free and scalable anymore. Performance will also degrade  
> dramatically.
>
> Besides, the more I think about thread-local/shared separation that is  
> going to come to D2, the more I see that there is absolutely no need to  
> make Phobos containers thread-safe. Most containers will be thread-local  
> and won't need any synchronization at all.

I meant, most essential ones (Array, Set, Map, HashMap, SList, DList, IntrusiveSList, IntrusiveDList etc).
Lock-free containers are needed, too, but I believe they should be designed after thread-unsafe ones.