java.nio.*Buffer read/write atomicity (original) (raw)
David M. Lloyd david.lloyd at redhat.com
Fri Dec 21 15:12:22 UTC 2012
- Previous message: java.nio.*Buffer read/write atomicity
- Next message: java.nio.*Buffer read/write atomicity
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: java.nio.*Buffer read/write atomicity
- Next message: java.nio.*Buffer read/write atomicity
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]