java.nio.*Buffer read/write atomicity

[Vitaly Davidovich]

Aleksey,

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.

As others have suggested, I think the right approach would be to create a
threadsafe version that's documented to be as such.

Just my $.02

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

> On 12/20/2012 09:11 PM, mark.reinhold at oracle.com wrote:
> > 2012/12/19 12:37 -0800, david.holmes at oracle.com:
> >> If multiple threads have to synchronize access to the buffer then the
> >> reads/writes do not need to be atomic. Atomicity is only needed when
> >> data races are allowed.
> >
> > Correct.
> >
> > Byte buffers, especially the direct variety, are all about performance.
> > Making operations upon them atomic is not a problem that needs to be
> > solved.
>
> I would say that you can have the read/write atomicity for heap
> ByteBuffers without the compromises in performance (i.e. like direct
> ByteBuffer does with full-width reads/writes) -- basically prune out the
> Java code which breaks ints into the series of bytes, and cram in
> Unsafe.putInt() against backing array.
>
> This is not about making the CAS updates, it is about making reads and
> writes appear indivisible. Seems to be a good thing even if unspec'ed.
>
> -Aleksey.
>