java.nio.*Buffer read/write atomicity (original) (raw)
Vitaly Davidovich vitalyd at gmail.com
Thu Dec 20 17:49:41 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 ]
Aleksey,
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.
As others have suggested, I think the right approach would be to create a threadsafe version that's documented to be as such.
Just my $.02
Sent from my phone On Dec 20, 2012 12:19 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com> wrote:
On 12/20/2012 09:11 PM, mark.reinhold at oracle.com wrote: > 2012/12/19 12:37 -0800, david.holmes at oracle.com: >> If multiple threads have to synchronize access to the buffer then the >> reads/writes do not need to be atomic. Atomicity is only needed when >> data races are allowed. > > Correct. > > Byte buffers, especially the direct variety, are all about performance. > Making operations upon them atomic is not a problem that needs to be > solved.
I would say that you can have the read/write atomicity for heap ByteBuffers without the compromises in performance (i.e. like direct ByteBuffer does with full-width reads/writes) -- basically prune out the Java code which breaks ints into the series of bytes, and cram in Unsafe.putInt() against backing array. This is not about making the CAS updates, it is about making reads and writes appear indivisible. Seems to be a good thing even if unspec'ed. -Aleksey.
- Previous message: java.nio.*Buffer read/write atomicity
- Next message: java.nio.*Buffer read/write atomicity
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]