java.nio.*Buffer read/write atomicity

[Vitaly Davidovich]

In the name of performance, go for it. :)

Vitaly

Sent from my phone
On Dec 20, 2012 1:22 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
wrote:

> The astonishment comes from this:
>   a. racy Unsafe.putInt(...) to byte[] is atomic*
>   b. racy direct ByteBuffer.putInt(...) is atomic*
>   c. racy heap ByteBuffer.putInt(...) is NOT!
>   d. racy heap ByteBuffer.asIntBuffer().put(...) is NOT atomic again!
>
> So then, the hacky code over the byte arrays appears more consistent
> than public API, without any solid reason for that? Granted, we can
> always put our fingers in our ears and sing "la-la-la, you were never
> guaranteed that", but I would say this is surprising inconsistency. And
> by the way direct ByteBuffers (inadvertently) deal with that, it's
> obvious we can do the same for heap ByteBuffers.
>
> I feel dumb for having to explain this, I should have probably publish
> the CR with the change and advocate it helps performance, fixing the
> atomicity issue under the cover. The atomicity does not have to be
> spec'ed, but I would certainly vote for it for the equivalent
> implementation.
>
> Sorry for mudding the quiet waters.
>
> -Aleksey.
>
> (*) subject to underlying hardware memory model, alignment, etc.
>
> On 12/20/2012 10:03 PM, Vitaly Davidovich wrote:
> > But why would there be astonishment/surprise here if it says it's not
> > threadsafe? I guess that's the part I'm having trouble understanding.
> >
> > Sent from my phone
> >
> > On Dec 20, 2012 12:54 PM, "Aleksey Shipilev"
> > <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>>
> wrote:
> >
> >     On 12/20/2012 09:49 PM, Vitaly Davidovich wrote:
> >     > Just curious - what's the driver for this? Suppose it did have full
> >     > width writes/reads - you still shouldn't use it in a data racey way
> >     > since it's not spec'd to be threadsafe and you can only observe
> torn
> >     > reads/writes if you access it without synchronization.
> >
> >     The driver is the infamous "principle of least astonishment", aided
> by
> >     my purism. Java is remarkable in the way it deals with races, trying
> to
> >     surprise the least when something breaks. I think the change that
> brings
> >     in more consistency without sacrificing maintainability and/or
> >     performance is the change we endorse, right?
> >
> >     -Aleksey.
> >
>
>