[concurrency-interest] Stricter read ordering

Kaiser, Peter Peter.Kaiser at compuware.com
Thu Apr 24 06:10:27 EDT 2014

Wouldn't it be possible to store each chunk in an individual byte array? Writes could simply exchange single arrays and safe publication to other threads would be much easier and more efficient. Reads would also be more efficient.

Best Regards, Peter

From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Peter Levart
Sent: Donnerstag, 24. April 2014 11:56
To: Tobias Lindaaker; concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] Stricter read ordering

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.

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.




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<mailto:Concurrency-interest at cs.oswego.edu>


The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a company registered in Vienna whose registered office is at 1120 Wien, Austria, Am Euro Platz 2 / Geb?ude G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140424/f85ff9e5/attachment-0001.html>

More information about the Concurrency-interest mailing list