Thanks all.
(I'm a picky reviewer myself, but sometimes I also approve changes that I
think are Meh)
On Tue, Mar 24, 2015 at 1:04 AM, David Holmes david.hol...@oracle.com
wrote:
On 24/03/2015 5:55 PM, Paul Sandoz wrote:
On Mar 24, 2015, at 12:27 AM, John Rose john.r.r...@oracle.com wrote:
On 24/03/2015 5:55 PM, Paul Sandoz wrote:
On Mar 24, 2015, at 12:27 AM, John Rose john.r.r...@oracle.com wrote:
Meanwhile, Paul Sandoz is working to refactor these aspects, creating a large
chunk of API that will be public, portable, and secure. You've got to
sympathize with him for not
On Mar 24, 2015, at 12:27 AM, John Rose john.r.r...@oracle.com wrote:
Meanwhile, Paul Sandoz is working to refactor these aspects, creating a large
chunk of API that will be public, portable, and secure. You've got to
sympathize with him for not wanting to run through all the inevitable
On Wed, Mar 11, 2015 at 2:12 AM, Paul Sandoz paul.san...@oracle.com wrote:
I am all for clearing up the language here, but think it prudent to hold
off doing much until the language for JMM revisions and VarHandle is
produced, then we can revisit.
I'm disappointed we can't add such a small
On Mar 23, 2015, at 1:24 PM, Martin Buchholz marti...@google.com wrote:
On Wed, Mar 11, 2015 at 2:12 AM, Paul Sandoz paul.san...@oracle.com wrote:
I am all for clearing up the language here, but think it prudent to hold
off doing much until the language for JMM revisions and VarHandle is
On Mar 10, 2015, at 8:06 PM, Martin Buchholz marti...@google.com wrote:
I agree with Andrew that the Unsafe API matters, and there are many
implementations of it (even multiple within openjdk itself!).
I still know of no reason why my proposed spec is wrong. If C11 support was
good and
I agree with Andrew that the Unsafe API matters, and there are many
implementations of it (even multiple within openjdk itself!).
I still know of no reason why my proposed spec is wrong. If C11 support
was good and ubiquitous, I would recommend using atomic_compare_exchange_strong
or C++
On 10/03/15 01:30, David Holmes wrote:
On 10/03/2015 2:21 AM, Martin Buchholz wrote:
On Mon, Mar 9, 2015 at 4:13 AM, David Holmes david.hol...@oracle.com
mailto:david.hol...@oracle.com wrote:
On 9/03/2015 7:27 PM, Andrew Haley wrote:
But who is to say that is the specification for
On 10/03/15 01:38, David Holmes wrote:
PS. You state: Corresponds to C11 atomic_compare_exchange_strong. Yet
that would match with the full bi-directional fences of the VM
implementation (due to memory_order_seq_cst), not a volatile read
followed by a volatile write (which would be
On 9/03/2015 7:27 PM, Andrew Haley wrote:
On 09/03/15 00:34, David Holmes wrote:
On 7/03/2015 6:49 AM, Martin Buchholz wrote:
A wee code review fer ya:
https://bugs.openjdk.java.net/browse/JDK-8074578
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-CAS-spec/
Sorry Martin but this
On 03/09/2015 11:13 AM, David Holmes wrote:
On 9/03/2015 7:27 PM, Andrew Haley wrote:
On 09/03/15 00:34, David Holmes wrote:
On 7/03/2015 6:49 AM, Martin Buchholz wrote:
A wee code review fer ya:
https://bugs.openjdk.java.net/browse/JDK-8074578
On Mon, Mar 9, 2015 at 4:13 AM, David Holmes david.hol...@oracle.com
wrote:
On 9/03/2015 7:27 PM, Andrew Haley wrote:
But who is to say that is the specification for the Unsafe API?
It's for us to say!
The public API's have a specification for what they provide to the
programmer. On
??
I mentally map Java volatile operations to C11 seq_cst because of the total
order over all operations on volatile variables.
Volatile reads and writes do not just have acquire/release semantics.
The java memory model does not (yet) have C11-style relaxed atomics (like
acquire or release)
On
On 10/03/2015 3:04 PM, Martin Buchholz wrote:
??
I mentally map Java volatile operations to C11 seq_cst because of the
total order over all operations on volatile variables.
Volatile reads and writes do not just have acquire/release semantics.
You may be right. The synchronization order (not
On 10/03/2015 2:21 AM, Martin Buchholz wrote:
On Mon, Mar 9, 2015 at 4:13 AM, David Holmes david.hol...@oracle.com
mailto:david.hol...@oracle.com wrote:
On 9/03/2015 7:27 PM, Andrew Haley wrote:
But who is to say that is the specification for the Unsafe API?
It's for us to say!
I
PS. You state: Corresponds to C11 atomic_compare_exchange_strong. Yet
that would match with the full bi-directional fences of the VM
implementation (due to memory_order_seq_cst), not a volatile read
followed by a volatile write (which would be memory_order_acq_rel).
On 09/03/15 00:34, David Holmes wrote:
On 7/03/2015 6:49 AM, Martin Buchholz wrote:
A wee code review fer ya:
https://bugs.openjdk.java.net/browse/JDK-8074578
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-CAS-spec/
Sorry Martin but this is neither accurate nor meaningful. It
On 7/03/2015 6:49 AM, Martin Buchholz wrote:
A wee code review fer ya:
https://bugs.openjdk.java.net/browse/JDK-8074578
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-CAS-spec/
Sorry Martin but this is neither accurate nor meaningful. It isn't
accurate because the actual
I didn't expect this to be controversial.
The spec for regular compareAndSet has similar wording.
I don't think it matters whether implementation is via a lock, because the
lock itself entails at least a volatile read and write.
As to which variable is being read/written to, it should be obvious
19 matches
Mail list logo
