RFC: naming for FrontTransversal and Transversal ranges

[Robert Jacques]

On Sat, 02 May 2009 10:23:13 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Denis Koroskin wrote:
>>> 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.
>
> How did you get to "most likely"? There's so many factors in the  
> equation. What is the alternative? Why wouldn't the code be lock-free?  
> Why would it not be scalable?

Because it dies a horrible death under contention. It's lock-free, but it  
isn't concurrent. Worse, the inner CAS loop is actually doing a lot of  
work, resulting in a lots of wasted CPU cycles. So as long as the write  
rarely, read many paradigm holds, it works. But try this with a stack or a  
queue and a good locking algorithm will beat you every time. Also, there's  
an issue with stale values for readers, but that's a separate thing.

>> 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 agree. But you also don't want to preclude using a shared container  
> either.

I think Phobos containers should come in two forms: shared and local. i.e.
shared Queue!T sq;   /// and
        Queue!T  q;
They don't need to be there at day one, but I think if they aren't able to  
be supported (or slow as molasses), well end of with two container sets  
and lots of code duplication.