[concurrency-interest] Stricter read ordering

Peter Levart peter.levart at gmail.com
Thu Apr 24 05:56:24 EDT 2014


On 04/24/2014 11:19 AM, Tobias Lindaaker wrote:
> Stanimir,
>
> 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.

Regards, Peter

>
> 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.
>>
>> 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 
> <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:
>>
>> 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 
> <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!)
>>
>> 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
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

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


More information about the Concurrency-interest mailing list