java.nio.*Buffer read/write atomicity (original) (raw)

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