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.shipi...@oracle.com> wrote: > On 12/20/2012 09:11 PM, mark.reinh...@oracle.com wrote: > > 2012/12/19 12:37 -0800, david.hol...@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. >
