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 ByteB
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 ag
In the name of performance, go for it. :)
Vitaly
Sent from my phone
On Dec 20, 2012 1:22 PM, "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(
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!
So then, the hacky code over the byte arrays ap
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"
wrote:
> On 12/20/2012 09:49 PM, Vitaly Davidovich wrote:
> > Just curious - what's the driv
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
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
Am 20.12.2012 18:18, schrieb Aleksey Shipilev:
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
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.
>
> B
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
Thanks for all the inputs.
I think I need to get off to concurrency-interest to ask what the
general public expectations are, to see whether we need to spec this
more accurately. Even though spec is explicit now about using Buffers
with synchronization, there is also a "reasonable behavior", that
I'm with David on this one - since BB specifically says that it's not
threadsafe I don't see why there would be any expectation of atomicity.
Same goes for IntBuffer or LongBuffer.
Vitaly
Sent from my phone
On Dec 19, 2012 6:23 PM, "Zhong Yu" wrote:
> Users are unlikely to expect multi-byte ato
Users are unlikely to expect multi-byte atomicity on a ByteBuffer.
However they are more likely to expect int-width atomicity on an
IntBuffer view of a ByteBuffer; such atomicity is unfortunately not
guaranteed either.
Zhong Yu
On Wed, Dec 19, 2012 at 11:48 AM, Aleksey Shipilev
wrote:
> Hi guys
Aleksey,
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.
David
On 20/12/2012 3:48 AM, Aleksey Shipilev wrote:
Hi guys,
I wanted to cross-check what's the expected behavior of
On 19/12/2012 18:56, Aleksey Shipilev wrote:
On 12/19/2012 10:45 PM, Alan Bateman wrote:
On memory model rules then there is is an outstanding bug to update the
buffer spec with at least minimal properties. Doug might remember the
discussion with Dave Dice about this a few years ago. I've always
On 12/19/2012 10:45 PM, Alan Bateman wrote:
> On memory model rules then there is is an outstanding bug to update the
> buffer spec with at least minimal properties. Doug might remember the
> discussion with Dave Dice about this a few years ago. I've always meant
> to do it but it never got to the
On 19/12/2012 17:48, Aleksey Shipilev wrote:
Hi guys,
I wanted to cross-check what's the expected behavior of Buffers with
respect to atomicity? Don't confuse the atomic operations (a la
j.u.c.atomic.*) and the read/write atomicity. Here's the concrete
example, should the assert always be true?
Hi guys,
I wanted to cross-check what's the expected behavior of Buffers with
respect to atomicity? Don't confuse the atomic operations (a la
j.u.c.atomic.*) and the read/write atomicity. Here's the concrete
example, should the assert always be true?
ByteBuffer buf = ByteBuffer.allocate(100);
18 matches
Mail list logo