java.nio.*Buffer read/write atomicity

[David M. Lloyd]

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.
>
> David
> ----
>
>> 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.
>>>
>>


-- 
- DML