java.nio.*Buffer read/write atomicity
Aleksey Shipilev
aleksey.shipilev at oracle.com
Thu Dec 20 11:43:08 UTC 2012
Thanks for all the inputs.
I think I need to get off to concurrency-interest to ask what the
general public expectations are, to see whether we need to spec this
more accurately. Even though spec is explicit now about using Buffers
with synchronization, there is also a "reasonable behavior", that we
would certainly like to take into the consideration.
Here's the link for the discussion:
http://cs.oswego.edu/pipermail/concurrency-interest/2012-December/010390.html
-Aleksey.
On 12/20/2012 04:21 AM, Vitaly Davidovich wrote:
> I'm with David on this one - since BB specifically says that it's not
> threadsafe I don't see why there would be any expectation of atomicity.
> Same goes for IntBuffer or LongBuffer.
>
> Vitaly
>
> Sent from my phone
>
> On Dec 19, 2012 6:23 PM, "Zhong Yu" <zhong.j.yu at gmail.com
> <mailto:zhong.j.yu at gmail.com>> wrote:
>
> Users are unlikely to expect multi-byte atomicity on a ByteBuffer.
>
> However they are more likely to expect int-width atomicity on an
> IntBuffer view of a ByteBuffer; such atomicity is unfortunately not
> guaranteed either.
>
> Zhong Yu
>
> On Wed, Dec 19, 2012 at 11:48 AM, Aleksey Shipilev
> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>>
> wrote:
> > Hi guys,
> >
> > I wanted to cross-check what's the expected behavior of Buffers with
> > respect to atomicity? Don't confuse the atomic operations (a la
> > j.u.c.atomic.*) and the read/write atomicity. Here's the concrete
> > example, should the assert always be true?
> >
> > ByteBuffer buf = ByteBuffer.allocate(100);
> > (publish $buf to both threads properly)
> > (start both threads)
> >
> > Thread 1:
> > buf.putInt(0, 42); // at position 0
> >
> > Thread 2:
> > int i = buf.getInt(0); // at position 0
> > Assert.assertTrue( (i == 0) || (i == 42) )
> >
> > Javadoc is silent about that, except for noting Buffers are not
> supposed
> > to be used from the multiple threads without synchronization. I would
> > anyway advocate to follow the atomicity behavior of plain fields and
> > arrays, and make these reads/writes atomic under the race.
> >
> > The apparent reason for at least BB to fail to be atomic is that we
> > read/write larger values byte-by-byte. Luckily, it appears to be
> easy to
> > fix (for a given endianness, we can just throw in the Unsafe call).
> > Before going out and submitting the RFE, I wanted to crosscheck if
> > somebody has strong feelings about this.
> >
> > Thanks,
> > Aleksey.
>
More information about the core-libs-dev
mailing list