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

Subject: Re: [boost] [Review] Lockfree review starts today, July 18th
From: Grund, Holger (Holger.Grund_at_[hidden])
Date: 2011-07-21 10:49:37

Thanks Tim,

> > 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.

> 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?

> > Is there any good way to override the allocation?
> 
> if the size of the ringbuffer is specified at runtime, there is no way
> for it, i should probably add allocator support. however this will only
> help, if your allocators force the memory regions into physical ram by
> using mlock() or the like and by touching them to avoid minor page
> faults.
> 
We usually just touch the memory and assume it will never be paged out (i.e. you just have a box with enough memory for your stuff and you don't run weird things on it). Large pages are usually implicitly locked on most operating systems -- so that's another cheap option.

> 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.

> in general i hesitate to add any performance numbers, because the
> performance heavily depends on the CPU that is used.
> 
And setting up a system for low latencies isn't exactly trivial these anymore either. Still, I have found a best-case comparison to be usually useful. Especially when you can just rerun the test in your own setup.

Say your consumer does nothing -- what's the highest produce rate you can get etc.

And, yes I understand that these things are highly dependent on the microarchitecture and OS & baseboard configuration.

Thanks!
-hg

--------------------------------------------------------------------------
NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.