[concurrency-interest] Stricter read ordering

Tobias Lindaaker thobes at gmail.com
Thu Apr 24 05:19:40 EDT 2014


Stanimir,

Yes, the data in the buffers range from 9 to 130 bytes per data item.

On 23 Apr 2014, at 17:57 , Stanimir Simeonoff <stanimir at riflexo.com> wrote:

> Just in case to make sure:
> You have more than just 2 ints, right? 
> On 64bit and aligned direct buffers you'd get all you want via put/getLong esp on LongBuffer as it always aligned.
> 
> Stanimir

-----

Peter,

I have looked at LeftRight, and MVCC in general, previously. I like these approaches, and we have it included as one of the alternatives we are benchmarking against the one I outlined in this thread. The drawbacks of a solution using two (or more) versions of the data is that it requires more memory (meaning we can fit less data into memory) and that it is less similar to our current code, requiring larger changes to implement. It's still an interesting alternative, so thank you for adding it to the discussion. However our current focus is to make sure that the different alternatives we are benchmarking are correct, so that the comparison is fair.

On 23 Apr 2014, at 23:25 , Peter Levart <peter.levart at gmail.com> wrote:

> Hi Tobias,
> 
> I you don't mind keeping 2 mirrored variants of your state (two mirrored memory mapped files in your case, or one file with duplicate/striped records) and applying all modifications to both copies, then the following might interest you:
> 
> http://sourceforge.net/projects/ccfreaks/files/papers/LeftRight/leftright-extended.pdf
> 
> Regards, Peter

-----

Hans,

Thank you for the reference, a very nice read, those examples are very good at illustrating the problems and solutions.

On 23 Apr 2014, at 19:26 , Hans Boehm <boehm at acm.org> wrote:

> The original code is essentially a reimplementation of Linux seqlocks.  The memory ordering issues are discussed in my MSPC 2012 paper, which you can find at http://www.hpl.hp.com/techreports/2012/HPL-2012-68.html .
> 
> (The C++ writer code in that paper, which should be uninteresting, and is beside the point, has a bug.  Don't copy!)
> 
> Hans
> 


-----

Roman and Alex,

Thank you for all your great insight and suggestions, I greatly appreciate it.
I'm going to re-read the JSR-133 cookbook a few times.

Cheers,
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140424/a8dddbfd/attachment.html>


More information about the Concurrency-interest mailing list