[concurrency-interest] Stricter read ordering
peter.levart at gmail.com
Thu Apr 24 05:56:24 EDT 2014
On 04/24/2014 11:19 AM, Tobias Lindaaker wrote:
> Yes, the data in the buffers range from 9 to 130 bytes per data item.
If data items could be broken into 64 or 32 bit chunks so that each
chunk contained a version counter (depending on the possible frequency
of updates it could be just a few bits) and those chunks could be read
and written atomically, then you could just read all the chunks of a
data item and check that the versions of all chunks match. The writer
would just have to increment the version counter of each chunk belonging
to data items updated.
> On 23 Apr 2014, at 17:57 , Stanimir Simeonoff <stanimir at riflexo.com
> <mailto: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.
> 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
> <mailto: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:
>> Regards, Peter
> 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
> <mailto: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!)
> 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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest