java.nio.*Buffer read/write atomicity
David M. Lloyd
david.lloyd at redhat.com
Fri Dec 21 15:12:22 UTC 2012
On 12/20/2012 06:44 PM, David Holmes wrote:
> On 21/12/2012 4:22 AM, Aleksey Shipilev 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!
> The only thing I find astonishing here is that anyone would spend time
> analysing how different non-thread-safe data structures behave in the
> face of data races. Seriously I think you are in a very small crowd :)
> Even the c-i discussion was all over the field with very little actual
> discussion of atomicity as such.
Well I reckon that atomicity might become important in the face of
buffer slices - particularly the practice of slicing up large buffers
into smaller buffers, for the purposes of pooling or whatever.
Especially if someone thinks it is a good idea to use weird unalignable
sizes for their slices.
> If there are performance issues that can be addressed here, or you can
> generally make this "better", then fine. But atomicity is not a problem
> here and the last thing we want is to encourage people to use these
> classes in racy contexts because they now think it is "safe" because of
> atomic accesses.
>> 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
>> Sorry for mudding the quiet waters.
>> (*) 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>>
>>> 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?
More information about the core-libs-dev