[concurrency-interest] Stricter read ordering

Stanimir Simeonoff stanimir at riflexo.com
Thu Apr 24 06:43:44 EDT 2014


If the ByteBuffers are direct (e.g. mapped ones, or just offheap memory)
that won't be usable. If they are plain heap buffers, there is no reason
not to use just normal java objects then.

Stanimir




On Thu, Apr 24, 2014 at 1:10 PM, Kaiser, Peter
<Peter.Kaiser at compuware.com>wrote:

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


More information about the Concurrency-interest mailing list