Re: [boost] [Review] Lockfree review starts today, July 18th

Subject: Re: [boost] [Review] Lockfree review starts today, July 18th
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-07-21 12:01:03

> > > ringbuffer<foo> x;
> > > ringbuffer<foo> y;
> > > 
> > > Consider a standard toolchain without fancy optimizations. Wouldn't
> > > this normally result in the x.read_pos and y.write_pos to be
> > 
> > allocated
> > 
> > > on the same cacheline.
> > 
> > in this case one could argue, that you should ensure the padding
> > manually :)
> 
> That seems counter-intuitive to me. If you expect users to do so that
> should probably be spelled out clearly.

well, i think this is not really a common case. if one wants to be sure, that 
there is absolutely no false sharing, one would have to pad the whole class to 
ensure that nothing before and nothing after the data structure will be placed 
in the same cache line. but i think going that far is overkill ...

> > nevertheless, there is one point that i should probably address: i
> > should enforce that neither read index, write index and the actual
> > ringbuffer array use different cache lines.
> 
> I'm having trouble understanding this. Do you mean they should go on
> different cachelines?

yes

> > the ringbuffer is a single-producer, single-consumer data structure. if
> > you use multiple producers, it will be corrupted!
> 
> My bad -- sorry haven't read the docs or code carefully.

i've now mentioned it explicitly in the reference section of each function.

cheers, tim