Should I avoid compareAndSet with value-based classes?

classic Classic list List threaded Threaded
101 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Vitaly Davidovich
I've skimmed this thread, so maybe missing something, but I agree with Kirk here.

This needs to be solved at the type system level, not runtime exceptions (nevermind the compatibility story).  A ValueBased class, IMO, is at most a lint - I have a hard time imagining how those classes can be converted to real VT when those exist.  No amount of javadoc will avoid breakage.  Without this being in the type system proper and thus making a compiler fail a build if misused.  == needs to stay as is, and any code today that uses == must be changed to only work on T=reference type when VT is introduced and must refuse compilation (and verification) if provided a VT.

How to enable CAS and the like for VT would be a separate matter.

On Fri, Jul 7, 2017 at 1:05 PM Kirk Pepperdine <[hidden email]> wrote:
>
> 3. The exception-throwing thing is IMO the healthy way to go IMO. I.e. throw some runtime exception when encountering an indentity-based operation on an instance of a value-based class. Hard to argue that "an exception should not be thrown here" given the clear warnings in the spec. My worry is mostly about coverage. Throwing exceptions in all cases where identity based operations are attempted would clearly be right, and healthy. But doing so only in some cases (and leaving some undefined behavior executing paths that don't throw exceptions) doesn't solve the problem [and may make things worse by encouraging false confidence]. Since no one *requires* us to throw an exception right now, JVM implementors will probably keep taking the lazy approach and not work hard on trying to achieve complete coverage. And since don't do it at all" is probably better/easier to verify than "do it in some places but not in others", we'll probably avoid it altogether for now. This *may* change when value-based optimizations materialize.

I think I’d have to (violently) disagree with this. There is a reason no one requires you to throw an exception when expressing equality and that is because this is a guaranteed property in the runtime. Without it you lose a fundamental property of the runtime.

— Kirk

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
--
Sent from my phone

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Alex Otenko
In reply to this post by Andrew Haley
I think there is a bit of a split mind here: what the value class instance is (is it Object-like in the language spec, so does it behave like references?), and what the value class instance is implemented as by the JVM (is it Object-like in the actual memory layout, so does it behave like a reference?).

The value class instance does not necessarily fit in a single machine word - time Instance certainly doesn’t. If the time Instance is “inlined” by the JVM, then you can’t guarantee atomicity of writes, and atomicity of reads also, so the reads also need to use a synchronized block - whether demand that explicitly from the programmer, or do that implicitly, like it’s done for volatile long on some platforms, does not matter. (Or use StampedLock, as Doug points out).

If it’s done implicitly by the JVM that “inlines” the value class instance, then there is no need to require extra steps from the programmer.


Alex


> On 7 Jul 2017, at 14:26, Andrew Haley <[hidden email]> wrote:
>
> On 07/07/17 13:27, Alex Otenko wrote:
>
>> If you are updating a reference, then CAS can also work.
>
> Well, that is the subject of some contention here, because the spec
> *explicitly* says you should not compare quality, and that is what a
> CAS does.  But the re is no need for a CAS; synchronized will do, and
> it allows you to call equals() rather than using reference equality.
>
> In practice, avoiding the use of reference equality is not a problem.
> That is my point.
>
>> If you are talking about imitating update of the reference by
>> mutating inlined object contents,
>
> You're not in this case.
>
>> then you do need synchronized for readers.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Should I avoid compareAndSet with value-based classes?

Gil Tene-2
In reply to this post by Andrew Haley

> On Jul 7, 2017, at 10:29 AM, Andrew Haley <[hidden email]> wrote:
>
> On 07/07/17 18:02, Gil Tene wrote:
>>
>> And in some cases locking (on something other than the reference to
>> the value-based class) will be perfectly sufficient. But in cases
>> where people seek lock-free or wait-free operations, locking may not
>> be an acceptable thing. E.g. Clocks and Instants are starting to
>> show up in the low latency paths of FinServ software due to MiFID 2
>> requirements, and that sort of code often tries to avoid locking
>> like the plague…
>
> Mmm, but then the question is whether something like this is more
> performant than locking:
>
>>    public void add(final Duration amountToAdd) {
>>        boolean success;
>>        do {
>>            BoxedInstant currentBoxedInstance = instantHolder.get();
>>            BoxedInstant newBoxedInstant =
>>                    new BoxedInstant(currentBoxedInstance.getInstant().plus(amountToAdd));
>>            success = instantHolder.compareAndSet(currentBoxedInstance, newBoxedInstant);
>>        } while (!success);
>>    }
>
> I'd argue that it's may well not be, because in the mostly-uncontended
> case acquiring a lock will sail straight through with no significant
> delay -- certainly no more than the compareAndSet we see here.  In the
> highly-contended case, locking may be preferable to the inter-thread
> thrashing this CAS loop might cause.  At least one of the threads
> would acquire the lock, and at least one of them would make some
> forward progress.  And the readers would be simpler and faster.  The
> lock used could be a fast spinlock: it doesn't have to block at the OS
> level.  But to know for sure you'd have to measure some real
> application behaviour.
>
> And the meta-question is whether people who avoid locking like the
> plague, even when it really is the simplest and cleanest thing to do,
> are doing it for good reasons or following a cargo cult.

The cult thing certainly does exist, but lock-freedom and wait-freedom as design criteria have real and good reasons too.

One typical and very real case is when a critical path thread cannot afford to block waiting for a non-critical path thread, even in a very rare case. Imagine that the two threads share a clock for some reason, and both participate in updating it (again, for some reason). The critical path thread will prefer taking the [potentially] extra hit of the code above in order to never be blocked behind the background thread owning a lock it is waiting on (which may have been context switched out for 10s of msec for one of many possible reasons).

This is a very common pattern in low latency systems where the critical path thread does operations that take low 10s of usec, but a background thread is doing some other thing [like updating a journal]. Such systems will often do much to protect the critical path thread from interference (e.g. pin it to a dedicated core, etc.).

>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Vitaly Davidovich
In reply to this post by Alex Otenko
At worst, you can extract/pack CAS-width-compatible value (e.g. long) and use that as the CAS storage.  Then materialize the VT from that on the fly after reading the storage value out.  If that's not possible, then you use locking, put it behind a heap object, or whatever other mechanism.

That's roughly what you do in the CLR, which doesn't allow CAS on structs (irrespective of its size).

On Fri, Jul 7, 2017 at 1:42 PM Alex Otenko <[hidden email]> wrote:
I think there is a bit of a split mind here: what the value class instance is (is it Object-like in the language spec, so does it behave like references?), and what the value class instance is implemented as by the JVM (is it Object-like in the actual memory layout, so does it behave like a reference?).

The value class instance does not necessarily fit in a single machine word - time Instance certainly doesn’t. If the time Instance is “inlined” by the JVM, then you can’t guarantee atomicity of writes, and atomicity of reads also, so the reads also need to use a synchronized block - whether demand that explicitly from the programmer, or do that implicitly, like it’s done for volatile long on some platforms, does not matter. (Or use StampedLock, as Doug points out).

If it’s done implicitly by the JVM that “inlines” the value class instance, then there is no need to require extra steps from the programmer.


Alex


> On 7 Jul 2017, at 14:26, Andrew Haley <[hidden email]> wrote:
>
> On 07/07/17 13:27, Alex Otenko wrote:
>
>> If you are updating a reference, then CAS can also work.
>
> Well, that is the subject of some contention here, because the spec
> *explicitly* says you should not compare quality, and that is what a
> CAS does.  But the re is no need for a CAS; synchronized will do, and
> it allows you to call equals() rather than using reference equality.
>
> In practice, avoiding the use of reference equality is not a problem.
> That is my point.
>
>> If you are talking about imitating update of the reference by
>> mutating inlined object contents,
>
> You're not in this case.
>
>> then you do need synchronized for readers.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Andrew Haley
In reply to this post by Alex Otenko
On 07/07/17 18:41, Alex Otenko wrote:

> The value class instance does not necessarily fit in a single
> machine word - time Instance certainly doesn’t. If the time Instance
> is “inlined” by the JVM, then you can’t guarantee atomicity of
> writes, and atomicity of reads also, so the reads also need to use a
> synchronized block - whether demand that explicitly from the
> programmer, or do that implicitly, like it’s done for volatile long
> on some platforms, does not matter. (Or use StampedLock, as Doug
> points out).

To be able to see a partly-constructed or overlapped instance of a
value-based class would be a clear violation of the JLS, so we don't
have to worry about that.  Any VM designer who wants to embed
instances of value-based classes is going to have to figure out how to
guarantee atomicity of updates.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Should I avoid compareAndSet with value-based classes?

Justin Sampson
In reply to this post by Gil Tene-2
Gil Tene wrote:

> public void setInstant(final Instant newInstant) {
>   instantHolder.get().setInstant(newInstant);
> }

This is broken because there's no volatile write. It needs to be instantHolder.set(new BoxedInstant(newInstant)), and then BoxedInstant can be immutable. I don't think you can get away from instantiating a new box each time, if your interpretation is correct.

Cheers,
Justin

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Should I avoid compareAndSet with value-based classes?

Gil Tene-2

On Jul 7, 2017, at 12:07 PM, Justin Sampson <[hidden email]> wrote:

Gil Tene wrote:

public void setInstant(final Instant newInstant) {
 instantHolder.get().setInstant(newInstant);
}

This is broken because there's no volatile write. It needs to be instantHolder.set(new BoxedInstant(newInstant)), and then BoxedInstant can be immutable. I don't think you can get away from instantiating a new box each time, if your interpretation is correct.

You are right that the code above is broken due to a missing volatile write. But I don't think we need to force allocation each time here. Instead, we can keep the box mutable and introduce the missing volatile write this way:
public void setInstant(final Instant newInstant) {
BoxedInstant boxedInstant = instantHolder.get();
boxedInstant.setInstant(newInstant);
instantHolder.set(boxedInstant); // to force volatile write
}
I believe that the various races possible between this  and other modifiers (other setInstant() caller, add() callers), are all possible in any case.


Cheers,
Justin



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Kirk Pepperdine
In reply to this post by Gil Tene-2

On Jul 7, 2017, at 7:32 PM, Gil Tene <[hidden email]> wrote:


On Jul 7, 2017, at 10:04 AM, Kirk Pepperdine <[hidden email]> wrote:


3. The exception-throwing thing is IMO the healthy way to go IMO. I.e. throw some runtime exception when encountering an indentity-based operation on an instance of a value-based class. Hard to argue that "an exception should not be thrown here" given the clear warnings in the spec. My worry is mostly about coverage. Throwing exceptions in all cases where identity based operations are attempted would clearly be right, and healthy. But doing so only in some cases (and leaving some undefined behavior executing paths that don't throw exceptions) doesn't solve the problem [and may make things worse by encouraging false confidence]. Since no one *requires* us to throw an exception right now, JVM implementors will probably keep taking the lazy approach and not work hard on trying to achieve complete coverage. And since don't do it at all" is probably better/easier to verify than "do it in some places but not in others", we'll probably avoid it altogether for now. This *may* change when value-based optimizations materialize.

I think I’d have to (violently) disagree with this. There is a reason no one requires you to throw an exception when expressing equality and that is because this is a guaranteed property in the runtime. Without it you lose a fundamental property of the runtime.

Synchronous exceptions can be thrown for example because (https://docs.oracle.com/javase/specs/jls/se7/html/jls-11.html#jls-11.1.2):
  • evaluation of an expression violates the normal semantics of the Java programming language (§15.6), such as an integer divide by zero.


Normal….
  • an error occurs while loading, linking, or initializing part of the program (§12.2§12.3§12.4); in this case, an instance of a subclass of LinkageError is thrown.


Again normal...
  • an internal error or resource limitation prevents the Java Virtual Machine from implementing the semantics of the Java programming language; in this case, an instance of a subclass of VirtualMethodError is thrown. [GT: this is mis-spelled in the spec. Should be VirtualMachineError]. 


Again expected….

I'd hope to have it qualify under the first bullet, but it is not listed in the specific list of runtime exception causes in 15.6. However, evaluating an == expression where one of the operands is an instance of a value-based class (and has no identity) can probably qualify under "an internal error or resource limitation prevents the Java Virtual Machine from implementing the semantics of the Java programming language" (third bullet). Especially when the Java SE spec explicitly says "Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects". 

Separately, asynchronous exceptions can be thrown anywhere in the code. E.g. An OOME can hit a == point in the code too.

I'd rather not make such exceptions a subclass of VirtualMachineError would be better tho…

There is only one 1. There is only one 2. I would expect in a value type where the value is a’, I would expect that there will only be one a’. Other wise you don’t have a value type, you have some weird form of boxing.

Kind regards,
Kirk


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Alex Otenko
In reply to this post by Gil Tene-2
A type with no identity certainly is a frankentype. I don’t see why the poor specification needs to be taken to its extreme interpretation. Conceptual clarity is more important than saving CPU cycles.

Having a type that is reified as something that does not have “a unique address” in memory (that we understand as the identity of Objects) is different from “no identity”.

Being unable to use “value type” instances for synchronization is perfectly reasonable - in the end, you aren’t meant to synchronize using random objects, and the whole purpose of supporting synchronization on every object is to ease construction of thread-safe code (through declaration of synchronized methods). If "the thing” is immutable, there is no need to support synchronization on those specific instances, and choosing such instances as the means of synchronizing something else requires justification, even if “the thing” subclasses from Object.

Restricting the meaning of identityHashCode is questionable, but in the end hinges on whether “the thing” is a subclass of an Object or not. If it is, then there are ways to support identityHashCode - even if there is no notion of “a unique address”.

Restricting the use of "==“ because of some compiler optimizations, is inventing obstacles. I don’t see why compiler problems of this sort should leak into the application programmer’s life, especially in the form of RandomExceptions and heisenbugs.


Alex


On 7 Jul 2017, at 18:32, Gil Tene <[hidden email]> wrote:


On Jul 7, 2017, at 10:04 AM, Kirk Pepperdine <[hidden email]> wrote:


3. The exception-throwing thing is IMO the healthy way to go IMO. I.e. throw some runtime exception when encountering an indentity-based operation on an instance of a value-based class. Hard to argue that "an exception should not be thrown here" given the clear warnings in the spec. My worry is mostly about coverage. Throwing exceptions in all cases where identity based operations are attempted would clearly be right, and healthy. But doing so only in some cases (and leaving some undefined behavior executing paths that don't throw exceptions) doesn't solve the problem [and may make things worse by encouraging false confidence]. Since no one *requires* us to throw an exception right now, JVM implementors will probably keep taking the lazy approach and not work hard on trying to achieve complete coverage. And since don't do it at all" is probably better/easier to verify than "do it in some places but not in others", we'll probably avoid it altogether for now. This *may* change when value-based optimizations materialize.

I think I’d have to (violently) disagree with this. There is a reason no one requires you to throw an exception when expressing equality and that is because this is a guaranteed property in the runtime. Without it you lose a fundamental property of the runtime.

Synchronous exceptions can be thrown for example because (https://docs.oracle.com/javase/specs/jls/se7/html/jls-11.html#jls-11.1.2):
  • evaluation of an expression violates the normal semantics of the Java programming language (§15.6), such as an integer divide by zero.

  • an error occurs while loading, linking, or initializing part of the program (§12.2§12.3§12.4); in this case, an instance of a subclass of LinkageError is thrown.

  • an internal error or resource limitation prevents the Java Virtual Machine from implementing the semantics of the Java programming language; in this case, an instance of a subclass of VirtualMethodError is thrown. [GT: this is mis-spelled in the spec. Should be VirtualMachineError]. 


I'd hope to have it qualify under the first bullet, but it is not listed in the specific list of runtime exception causes in 15.6. However, evaluating an == expression where one of the operands is an instance of a value-based class (and has no identity) can probably qualify under "an internal error or resource limitation prevents the Java Virtual Machine from implementing the semantics of the Java programming language" (third bullet). Especially when the Java SE spec explicitly says "Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects". 

Separately, asynchronous exceptions can be thrown anywhere in the code. E.g. An OOME can hit a == point in the code too.

I'd rather not make such exceptions a subclass of VirtualMachineError would be better tho...


— Kirk

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Gil Tene-2
Alex, your statements below are all arguments for why value-based classes (as specified) and value types (as they seem to be headed) should not exist as subclasses of Object. As noted before, I'd probably be on your side if that one.

But they do exist, and they (very clearly and explicitly) have no identity. We can't change that fact. We can avoid using them if we want. But we probably can't use them and argue that what we are using should be behaving in some directly-opposite-from-their-specification way.

For vale-based classes, the meaning of  == , identityHashCode, and synchronization are all clearly, explicitly and loudly undefined, promising unpredictable behavior. For value types it is not yet clear if the == operand will be similarly (explicitly) undefined, or if it will have a new meaning (act like == on an int), but things are pretty clear when it comes to identityHashCode and synchronization.

The reasoning for these value-based classes and value types goes far beyond compiler optimizations. And I'm not the one arguing for them.

My arguments here are not about trying to justify some compiler optimizations, or trying to justify the choices of making these things subclasses the Object. They are about pointing out the actual meaning of things as defined and the (very high risk) of coding against it based on a hope that some temporarily observed behavior is actually reliable, when everything that describes what it does says otherwise. My mentions of potential optimizations are simply attempts to demonstrate how strange things can happen to code that does these "may cause unpredictable behavior" things.

Sent from my iPad

On Jul 7, 2017, at 4:22 PM, Alex Otenko <[hidden email]> wrote:

A type with no identity certainly is a frankentype. I don’t see why the poor specification needs to be taken to its extreme interpretation. Conceptual clarity is more important than saving CPU cycles.

Having a type that is reified as something that does not have “a unique address” in memory (that we understand as the identity of Objects) is different from “no identity”.

Being unable to use “value type” instances for synchronization is perfectly reasonable - in the end, you aren’t meant to synchronize using random objects, and the whole purpose of supporting synchronization on every object is to ease construction of thread-safe code (through declaration of synchronized methods). If "the thing” is immutable, there is no need to support synchronization on those specific instances, and choosing such instances as the means of synchronizing something else requires justification, even if “the thing” subclasses from Object.

Restricting the meaning of identityHashCode is questionable, but in the end hinges on whether “the thing” is a subclass of an Object or not. If it is, then there are ways to support identityHashCode - even if there is no notion of “a unique address”.

Restricting the use of "==“ because of some compiler optimizations, is inventing obstacles. I don’t see why compiler problems of this sort should leak into the application programmer’s life, especially in the form of RandomExceptions and heisenbugs.


Alex


On 7 Jul 2017, at 18:32, Gil Tene <[hidden email]> wrote:


On Jul 7, 2017, at 10:04 AM, Kirk Pepperdine <[hidden email]> wrote:


3. The exception-throwing thing is IMO the healthy way to go IMO. I.e. throw some runtime exception when encountering an indentity-based operation on an instance of a value-based class. Hard to argue that "an exception should not be thrown here" given the clear warnings in the spec. My worry is mostly about coverage. Throwing exceptions in all cases where identity based operations are attempted would clearly be right, and healthy. But doing so only in some cases (and leaving some undefined behavior executing paths that don't throw exceptions) doesn't solve the problem [and may make things worse by encouraging false confidence]. Since no one *requires* us to throw an exception right now, JVM implementors will probably keep taking the lazy approach and not work hard on trying to achieve complete coverage. And since don't do it at all" is probably better/easier to verify than "do it in some places but not in others", we'll probably avoid it altogether for now. This *may* change when value-based optimizations materialize.

I think I’d have to (violently) disagree with this. There is a reason no one requires you to throw an exception when expressing equality and that is because this is a guaranteed property in the runtime. Without it you lose a fundamental property of the runtime.

Synchronous exceptions can be thrown for example because (https://docs.oracle.com/javase/specs/jls/se7/html/jls-11.html#jls-11.1.2):
  • evaluation of an expression violates the normal semantics of the Java programming language (§15.6), such as an integer divide by zero.

  • an error occurs while loading, linking, or initializing part of the program (§12.2§12.3§12.4); in this case, an instance of a subclass of LinkageError is thrown.

  • an internal error or resource limitation prevents the Java Virtual Machine from implementing the semantics of the Java programming language; in this case, an instance of a subclass of VirtualMethodError is thrown. [GT: this is mis-spelled in the spec. Should be VirtualMachineError]. 


I'd hope to have it qualify under the first bullet, but it is not listed in the specific list of runtime exception causes in 15.6. However, evaluating an == expression where one of the operands is an instance of a value-based class (and has no identity) can probably qualify under "an internal error or resource limitation prevents the Java Virtual Machine from implementing the semantics of the Java programming language" (third bullet). Especially when the Java SE spec explicitly says "Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects". 

Separately, asynchronous exceptions can be thrown anywhere in the code. E.g. An OOME can hit a == point in the code too.

I'd rather not make such exceptions a subclass of VirtualMachineError would be better tho...


— Kirk

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Alex Otenko
Sure, so it should change to a sensible definition. :-)

As such there isn’t even a generic way of determining whether something is a "value-based” instance or not - not even at runtime.

Alex

On 8 Jul 2017, at 07:38, Gil Tene <[hidden email]> wrote:

Alex, your statements below are all arguments for why value-based classes (as specified) and value types (as they seem to be headed) should not exist as subclasses of Object. As noted before, I'd probably be on your side if that one.

But they do exist, and they (very clearly and explicitly) have no identity. We can't change that fact. We can avoid using them if we want. But we probably can't use them and argue that what we are using should be behaving in some directly-opposite-from-their-specification way.

For vale-based classes, the meaning of  == , identityHashCode, and synchronization are all clearly, explicitly and loudly undefined, promising unpredictable behavior. For value types it is not yet clear if the == operand will be similarly (explicitly) undefined, or if it will have a new meaning (act like == on an int), but things are pretty clear when it comes to identityHashCode and synchronization.

The reasoning for these value-based classes and value types goes far beyond compiler optimizations. And I'm not the one arguing for them.

My arguments here are not about trying to justify some compiler optimizations, or trying to justify the choices of making these things subclasses the Object. They are about pointing out the actual meaning of things as defined and the (very high risk) of coding against it based on a hope that some temporarily observed behavior is actually reliable, when everything that describes what it does says otherwise. My mentions of potential optimizations are simply attempts to demonstrate how strange things can happen to code that does these "may cause unpredictable behavior" things.

Sent from my iPad

On Jul 7, 2017, at 4:22 PM, Alex Otenko <[hidden email]> wrote:

A type with no identity certainly is a frankentype. I don’t see why the poor specification needs to be taken to its extreme interpretation. Conceptual clarity is more important than saving CPU cycles.

Having a type that is reified as something that does not have “a unique address” in memory (that we understand as the identity of Objects) is different from “no identity”.

Being unable to use “value type” instances for synchronization is perfectly reasonable - in the end, you aren’t meant to synchronize using random objects, and the whole purpose of supporting synchronization on every object is to ease construction of thread-safe code (through declaration of synchronized methods). If "the thing” is immutable, there is no need to support synchronization on those specific instances, and choosing such instances as the means of synchronizing something else requires justification, even if “the thing” subclasses from Object.

Restricting the meaning of identityHashCode is questionable, but in the end hinges on whether “the thing” is a subclass of an Object or not. If it is, then there are ways to support identityHashCode - even if there is no notion of “a unique address”.

Restricting the use of "==“ because of some compiler optimizations, is inventing obstacles. I don’t see why compiler problems of this sort should leak into the application programmer’s life, especially in the form of RandomExceptions and heisenbugs.


Alex


On 7 Jul 2017, at 18:32, Gil Tene <[hidden email]> wrote:


On Jul 7, 2017, at 10:04 AM, Kirk Pepperdine <[hidden email]> wrote:


3. The exception-throwing thing is IMO the healthy way to go IMO. I.e. throw some runtime exception when encountering an indentity-based operation on an instance of a value-based class. Hard to argue that "an exception should not be thrown here" given the clear warnings in the spec. My worry is mostly about coverage. Throwing exceptions in all cases where identity based operations are attempted would clearly be right, and healthy. But doing so only in some cases (and leaving some undefined behavior executing paths that don't throw exceptions) doesn't solve the problem [and may make things worse by encouraging false confidence]. Since no one *requires* us to throw an exception right now, JVM implementors will probably keep taking the lazy approach and not work hard on trying to achieve complete coverage. And since don't do it at all" is probably better/easier to verify than "do it in some places but not in others", we'll probably avoid it altogether for now. This *may* change when value-based optimizations materialize.

I think I’d have to (violently) disagree with this. There is a reason no one requires you to throw an exception when expressing equality and that is because this is a guaranteed property in the runtime. Without it you lose a fundamental property of the runtime.

Synchronous exceptions can be thrown for example because (https://docs.oracle.com/javase/specs/jls/se7/html/jls-11.html#jls-11.1.2):
  • evaluation of an expression violates the normal semantics of the Java programming language (§15.6), such as an integer divide by zero.

  • an error occurs while loading, linking, or initializing part of the program (§12.2§12.3§12.4); in this case, an instance of a subclass of LinkageError is thrown.

  • an internal error or resource limitation prevents the Java Virtual Machine from implementing the semantics of the Java programming language; in this case, an instance of a subclass of VirtualMethodError is thrown. [GT: this is mis-spelled in the spec. Should be VirtualMachineError]. 


I'd hope to have it qualify under the first bullet, but it is not listed in the specific list of runtime exception causes in 15.6. However, evaluating an == expression where one of the operands is an instance of a value-based class (and has no identity) can probably qualify under "an internal error or resource limitation prevents the Java Virtual Machine from implementing the semantics of the Java programming language" (third bullet). Especially when the Java SE spec explicitly says "Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects". 

Separately, asynchronous exceptions can be thrown anywhere in the code. E.g. An OOME can hit a == point in the code too.

I'd rather not make such exceptions a subclass of VirtualMachineError would be better tho...


— Kirk

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Andrew Haley
In reply to this post by Gil Tene-2
On 08/07/17 07:38, Gil Tene wrote:

> My arguments here are not about trying to justify some compiler
> optimizations, or trying to justify the choices of making these
> things subclasses the Object. They are about pointing out the actual
> meaning of things as defined and the (very high risk) of coding
> against it based on a hope that some temporarily observed behavior
> is actually reliable, when everything that describes what it does
> says otherwise.

I disagree with this interpretation.  You're interpreting the language
in that paragraph as overriding some fundamental properties in the JLS.

In the case of C, the thing to do would be to ask for a clarification,
but I suspect that if we asked, say, John Rose, Alex Buckley, and
Brian Goetz we'd get different answers.  ;-)

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Remi Forax
In reply to this post by Alex Otenko
@Alex
Not yet, but at some point in the future, you will have a root of all value types and a common super type between objects, value types and primitives.

@Gil:
== already maps into different bytecodes, for value types, you can introduce a vcmp that compares all fields.

@all,
The in-progress writing about the minimal value type spec is here:
  http://cr.openjdk.java.net/~dlsmith/values.html
There are currently two prototypes of that the MVT spec, one in the valhalla workspace of the OpenJDK and one by IBM.

Then we will move to a more complex spec (called full value type spec) that will deal with the interaction between the different kind of types and also includes the support of generics.

Rémi


De: "Alex Otenko" <[hidden email]>
À: "Gil Tene" <[hidden email]>
Cc: "concurrency-interest" <[hidden email]>
Envoyé: Samedi 8 Juillet 2017 09:26:46
Objet: Re: [concurrency-interest] Should I avoid compareAndSet with        value-based classes?
Sure, so it should change to a sensible definition. :-)

As such there isn’t even a generic way of determining whether something is a "value-based” instance or not - not even at runtime.

Alex

On 8 Jul 2017, at 07:38, Gil Tene <[hidden email]> wrote:

Alex, your statements below are all arguments for why value-based classes (as specified) and value types (as they seem to be headed) should not exist as subclasses of Object. As noted before, I'd probably be on your side if that one.

But they do exist, and they (very clearly and explicitly) have no identity. We can't change that fact. We can avoid using them if we want. But we probably can't use them and argue that what we are using should be behaving in some directly-opposite-from-their-specification way.

For vale-based classes, the meaning of  == , identityHashCode, and synchronization are all clearly, explicitly and loudly undefined, promising unpredictable behavior. For value types it is not yet clear if the == operand will be similarly (explicitly) undefined, or if it will have a new meaning (act like == on an int), but things are pretty clear when it comes to identityHashCode and synchronization.

The reasoning for these value-based classes and value types goes far beyond compiler optimizations. And I'm not the one arguing for them.

My arguments here are not about trying to justify some compiler optimizations, or trying to justify the choices of making these things subclasses the Object. They are about pointing out the actual meaning of things as defined and the (very high risk) of coding against it based on a hope that some temporarily observed behavior is actually reliable, when everything that describes what it does says otherwise. My mentions of potential optimizations are simply attempts to demonstrate how strange things can happen to code that does these "may cause unpredictable behavior" things.

Sent from my iPad

On Jul 7, 2017, at 4:22 PM, Alex Otenko <[hidden email]> wrote:

A type with no identity certainly is a frankentype. I don’t see why the poor specification needs to be taken to its extreme interpretation. Conceptual clarity is more important than saving CPU cycles.

Having a type that is reified as something that does not have “a unique address” in memory (that we understand as the identity of Objects) is different from “no identity”.

Being unable to use “value type” instances for synchronization is perfectly reasonable - in the end, you aren’t meant to synchronize using random objects, and the whole purpose of supporting synchronization on every object is to ease construction of thread-safe code (through declaration of synchronized methods). If "the thing” is immutable, there is no need to support synchronization on those specific instances, and choosing such instances as the means of synchronizing something else requires justification, even if “the thing” subclasses from Object.

Restricting the meaning of identityHashCode is questionable, but in the end hinges on whether “the thing” is a subclass of an Object or not. If it is, then there are ways to support identityHashCode - even if there is no notion of “a unique address”.

Restricting the use of "==“ because of some compiler optimizations, is inventing obstacles. I don’t see why compiler problems of this sort should leak into the application programmer’s life, especially in the form of RandomExceptions and heisenbugs.


Alex


On 7 Jul 2017, at 18:32, Gil Tene <[hidden email]> wrote:


On Jul 7, 2017, at 10:04 AM, Kirk Pepperdine <[hidden email]> wrote:


3. The exception-throwing thing is IMO the healthy way to go IMO. I.e. throw some runtime exception when encountering an indentity-based operation on an instance of a value-based class. Hard to argue that "an exception should not be thrown here" given the clear warnings in the spec. My worry is mostly about coverage. Throwing exceptions in all cases where identity based operations are attempted would clearly be right, and healthy. But doing so only in some cases (and leaving some undefined behavior executing paths that don't throw exceptions) doesn't solve the problem [and may make things worse by encouraging false confidence]. Since no one *requires* us to throw an exception right now, JVM implementors will probably keep taking the lazy approach and not work hard on trying to achieve complete coverage. And since don't do it at all" is probably better/easier to verify than "do it in some places but not in others", we'll probably avoid it altogether for now. This *may* change when value-based optimizations materialize.

I think I’d have to (violently) disagree with this. There is a reason no one requires you to throw an exception when expressing equality and that is because this is a guaranteed property in the runtime. Without it you lose a fundamental property of the runtime.

Synchronous exceptions can be thrown for example because (https://docs.oracle.com/javase/specs/jls/se7/html/jls-11.html#jls-11.1.2):
  • evaluation of an expression violates the normal semantics of the Java programming language (§15.6), such as an integer divide by zero.

  • an error occurs while loading, linking, or initializing part of the program (§12.2§12.3§12.4); in this case, an instance of a subclass of LinkageError is thrown.

  • an internal error or resource limitation prevents the Java Virtual Machine from implementing the semantics of the Java programming language; in this case, an instance of a subclass of VirtualMethodError is thrown. [GT: this is mis-spelled in the spec. Should be VirtualMachineError]. 


I'd hope to have it qualify under the first bullet, but it is not listed in the specific list of runtime exception causes in 15.6. However, evaluating an == expression where one of the operands is an instance of a value-based class (and has no identity) can probably qualify under "an internal error or resource limitation prevents the Java Virtual Machine from implementing the semantics of the Java programming language" (third bullet). Especially when the Java SE spec explicitly says "Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects". 

Separately, asynchronous exceptions can be thrown anywhere in the code. E.g. An OOME can hit a == point in the code too.

I'd rather not make such exceptions a subclass of VirtualMachineError would be better tho...


— Kirk

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Gil Tene-2
In reply to this post by Andrew Haley

> On Jul 8, 2017, at 1:19 AM, Andrew Haley <[hidden email]> wrote:
>
> On 08/07/17 07:38, Gil Tene wrote:
>
>> My arguments here are not about trying to justify some compiler
>> optimizations, or trying to justify the choices of making these
>> things subclasses the Object. They are about pointing out the actual
>> meaning of things as defined and the (very high risk) of coding
>> against it based on a hope that some temporarily observed behavior
>> is actually reliable, when everything that describes what it does
>> says otherwise.
>
> I disagree with this interpretation.  You're interpreting the language
> in that paragraph as overriding some fundamental properties in the JLS.

To keep this to a simple case that

What specific property of the JLS requires that == not be always-false?

I.e., what is it in the JLS that requires that this loop ever terminate when there is no external interference by another thread?:

  // David Lloyd's example from earlier in the thread (Jul 6, 10:48AM PDT):
  AtomicReference<Instant> atomic;
  Instant a, b;
  ...
  do {
      a = atomic.get();
      b = compute(a);
  } while (! atomic.compareAndSet(a, b));


or for that matter, that this loop ever terminate when there is no external interference by another thread?:

  volatile Instant thing;
  Instant a, b;
  …
  boolean success = false;
  do {
      a = thing;
      b = compute(a);
      if (thing == a) {
          thing = b;
          success = true;      
      }
  } while (!success);

The termination of both of these loops relies on the notion of identity (the logical value of a reference) being preserved between the reading of a reference to an instance of a value-based class from memory, and the eventual comparison of that instance's reference with another one stored in a memory location.

I'm really asking… I'd love to find something in the JLS that says this must be preserved, and thereby contradict the statements that say that instances of value-based classes "are freely substitutable when equal" and "Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects".

I'd like to point out that Instant happens to be one of those cool ""partially compressible value" classes who's value cannot be fully represented with a single 64 bit value, but where "a wide and interesting range" of values can be: specifically, all the possible values of Instant between the epoch and some time in the year 2043 *can* be represented in 63 bits, making smalltalk-like inlined "it's not a pointer, it's a value" representations very possible (e.g. negative references are actual the values) and appealing for many reasons (both space and speed). This works as long as both identity and type can be erased from the contents without hurting computations [which can be done safely when stored in registers whose type is known, for example]. And this quality is specifically provided by the documentation of the type as a value-based class.

However, since it is possible for instances of Instant to be stored in locations that do not have this quality [e.g. Object fields, or even known-to-be-of-type-Instant fields in memory depending on implementation], each possible "compressible value" also needs a non-compressed representation in a heap-based object contents form. This means that the value in the memory location may be a true reference, while the value we read into local variables may not be, at least for a wide range of possible values. And that in turn means that the loops above will never terminate (since they will never be able to show that the reference contents of "atomic" or of "thing" is == to the value in a).

>
> In the case of C, the thing to do would be to ask for a clarification,
> but I suspect that if we asked, say, John Rose, Alex Buckley, and
> Brian Goetz we'd get different answers.  ;-)
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Gil Tene-2
With all this said (and I absolutely think that e.g. it should be expected that loops like my examples from the previous post may never terminate), this discussion has made me come up with a way to (I *think*) safely apply CAS to instances of Instant (and on any other instances that happen to be of value-based classes) as long as we code the CAS and the type it operates on carefully. I believe it is safe to do so as long as the field being CAS'ed into is declared as an Object and NOT as an Instant. By casting from Object to Instant to perform Instant operations [e.g. adding a duration] while preserving the Object form for the thing being compared in the CAS operation, I believe the CAS remains valid. See code below.

The reason that I believe this approach is inherently safe is that the contents of fields and local variables of type Object are [I think] required to retain identity-sensitive operation behaviors regardless of the actual (derived from Object) type of the current contents. The contents of fields and variables *known* to be of type Instant (and of other value-based classes that are inherited from Object) may lose identity information and produce unpredictable behaviors when used with identity-sensitive operations, based on the specification of the behaviors of value-based classes. However, this freedom to lose track of identity does not extend to fields and variables of type Object (or other non-value-based classes). 

In effect, I believe that the JVM is required to "box" instances of value-based classes in actual object references to actual objects with actual identity when storing them in fields or variables of a type that is not a value-based class. And all identity-based operations done on those fields and variables remain as-expected regardless of whether or not the contents is a reference to an instance of a value-based class. This quality is lost once something is cast to a value-based class (for storage in either a variable or field). In back-and-forth casting (implicit or explicit), the identities of objects that are created by casting back to Object does not have to remain the same as the identities of the original Objects cast from to a value-based class.

[** in this logic, "field" includes an array element]

This also leads me to [partially] retract my suggestion for throwing exceptions when encountering identity-based operations on instances of value-based classes. Such exceptions clearly shouldn't be thrown when the declared types of the operands involved are not value-based classes (even if the contents is of those type). I still think that throwing exceptions when the declared types are value-based classes could make sense, but this can actually be done better by the Java compiler refusing to compile such code (and it should know enough to do that, since the types are declared).

Since Generics do reification, this stuff would be un-enforceable in the generics source code. But it can still be enforced in code that uses generics, e.g. a AtomicReference<Object>.compareAndSet() can still refuse [at compile time] to accept a declared-as-value-based-class type as it's "expected" parameter. 
public class MutableClock {

public static MutableClock create(final Instant instant, final ZoneId zone) {
return new MutableClock(
new AtomicReference<>(instant),
zone);
}

// Instants are held in an Object field to allow identity-based CAS operations:
private final AtomicReference<Object> instantHolder;
private final ZoneId zone;

private MutableClock(
final AtomicReference<Object> instantHolder,
final ZoneId zone) {
this.instantHolder = instantHolder;
this.zone = zone;
}

public Instant instant() {
return (Instant) instantHolder.get();
}

public ZoneId getZone() {
return zone;
}

public void setInstant(final Instant newInstant) {
instantHolder.set(newInstant);
}

void add(Duration amountToAdd) {
boolean success = false;
do {
Object currentContents = instantHolder.get();
// ((Instant) currentContents) may have no identity, but currentContents does...
Instant newInstant = ((Instant) currentContents).plus(amountToAdd);
// Compare part of CAS would not be valid for an Instant field,
// but is valid for an Object field:
success = instantHolder.compareAndSet(currentContents, newInstant);
} while (!success);

// the above is equivalent to this, I believe:
// instantHolder.updateAndGet(instant -> ((Instant)instant).plus(amountToAdd));
}

public MutableClock withZone(final ZoneId newZone) {
// conveniently, AtomicReference also acts as a
// vehicle for "shared updates" between instances:
return new MutableClock(instantHolder, newZone);
}
}




On Jul 8, 2017, at 5:22 AM, Gil Tene <[hidden email]> wrote:


On Jul 8, 2017, at 1:19 AM, Andrew Haley <[hidden email]> wrote:

On 08/07/17 07:38, Gil Tene wrote:

My arguments here are not about trying to justify some compiler
optimizations, or trying to justify the choices of making these
things subclasses the Object. They are about pointing out the actual
meaning of things as defined and the (very high risk) of coding
against it based on a hope that some temporarily observed behavior
is actually reliable, when everything that describes what it does
says otherwise.

I disagree with this interpretation.  You're interpreting the language
in that paragraph as overriding some fundamental properties in the JLS.

To keep this to a simple case that

What specific property of the JLS requires that == not be always-false?

I.e., what is it in the JLS that requires that this loop ever terminate when there is no external interference by another thread?:

 // David Lloyd's example from earlier in the thread (Jul 6, 10:48AM PDT):
 AtomicReference<Instant> atomic;
 Instant a, b;
 ...
 do {
     a = atomic.get();
     b = compute(a);
 } while (! atomic.compareAndSet(a, b));


or for that matter, that this loop ever terminate when there is no external interference by another thread?:

 volatile Instant thing;
 Instant a, b;
 …
 boolean success = false;
 do {
     a = thing;
     b = compute(a);
     if (thing == a) {
         thing = b;
         success = true;      
     }
 } while (!success);

The termination of both of these loops relies on the notion of identity (the logical value of a reference) being preserved between the reading of a reference to an instance of a value-based class from memory, and the eventual comparison of that instance's reference with another one stored in a memory location.

I'm really asking… I'd love to find something in the JLS that says this must be preserved, and thereby contradict the statements that say that instances of value-based classes "are freely substitutable when equal" and "Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects".

I'd like to point out that Instant happens to be one of those cool ""partially compressible value" classes who's value cannot be fully represented with a single 64 bit value, but where "a wide and interesting range" of values can be: specifically, all the possible values of Instant between the epoch and some time in the year 2043 *can* be represented in 63 bits, making smalltalk-like inlined "it's not a pointer, it's a value" representations very possible (e.g. negative references are actual the values) and appealing for many reasons (both space and speed). This works as long as both identity and type can be erased from the contents without hurting computations [which can be done safely when stored in registers whose type is known, for example]. And this quality is specifically provided by the documentation of the type as a value-based class.

However, since it is possible for instances of Instant to be stored in locations that do not have this quality [e.g. Object fields, or even known-to-be-of-type-Instant fields in memory depending on implementation], each possible "compressible value" also needs a non-compressed representation in a heap-based object contents form. This means that the value in the memory location may be a true reference, while the value we read into local variables may not be, at least for a wide range of possible values. And that in turn means that the loops above will never terminate (since they will never be able to show that the reference contents of "atomic" or of "thing" is == to the value in a).


In the case of C, the thing to do would be to ask for a clarification,
but I suspect that if we asked, say, John Rose, Alex Buckley, and
Brian Goetz we'd get different answers.  ;-)

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Gregg Wonderly-3
In reply to this post by Alex Otenko
You are talking about a different language than Java then.   Identity vs equality is everywhere in my code.  I use both to do exactly what I mean.  Identity is the same instance that I created and referenced somewhere.  Equals is contains the same value.  There is a big different between is the same object and contains the same values.

Gregg

> On Jul 6, 2017, at 4:23 PM, Gil Tene <[hidden email]> wrote:
>
>
>> On Jul 6, 2017, at 1:09 PM, Alex Otenko <[hidden email]> wrote:
>>
>> :-) It’s NaN, but for the objects.
>>
>
> Well put. And a very good analogy. The identity of an instance of a value-based classes may act like a NaN at any time. And x == x is false when x is a NaN...
>
>> Using “equals” is just as ugly. It has completely different semantics.
>
>
>>
>> equality
>> equivalence
>> homotopy
>
> And == for objects (which means "same identity") is [I believe] different from all of the above.
>
> Alas, we don't have a well established meaning for .equivalent() in Java.
>
>>
>> all talk about sameness of things. I would tell the “it’s not as horrifying” crowd that it is absolutely wrong to force me to use equivalence where I mean equality. That’s the horrifying thing.
>>
>> It’s not “more correct” to use “equals()” instead of “==“. Because it is not an optimisation, it just has a different meaning. Optional(x).equals(Optional(y)), if x.equals(y), but it doesn’t mean I don’t care which one is referenced - exactly because x and y do have identities.
>
> Agreed.
>
> Alas, being immutable and non-constrictble (created only by factories) doesn't actually mean non-null everywhere… Super-annoyingly, it is perfectly "valid" (as in will compile and run something) to pass a null argument when an Optional is expected…
>
> Interesting mention of "nullability": http://mail.openjdk.java.net/pipermail/valhalla-dev/2015-January/000555.html , and a discussion of the subject in general (with some good links) here: https://blog.codefx.org/java/value-based-classes/ . I especially like the specific quotes from sources:
>
> -  "Optional is new, and the disclaimers arrived on day 1. Integer, on the other hand, is probably hopelessly polluted, and I am sure that it would break gobs of important code if Integer ceased to be lockable (despite what we may think of such a practice.)"
>
> - "In Java 8 value types are preceded by value-based classes. Their precise relation in the future is unclear but it could be similar to that of boxed and unboxed primitives (e.g. Integer and  int). Additionally, the compiler will likely be free to silently switch between the two to improve performance. Exactly that switching back and forth, i.e. removing and later recreating a reference, also forbids identity-based mechanisms to be applied to value-based classes."
>
> removing and later recreating a reference…. That's certainly in the cars.
>
>
>>
>>
>> There is sense in having a concept of a class whose objects convey no meaning except the existence of extra structure with its own virtual method table around some other values. But language needs support for safe use of them.
>>
>>
>> Alex
>>
>>> On 6 Jul 2017, at 20:12, Gil Tene <[hidden email]> wrote:
>>>
>>> The "it's not as horrifying as you might think" crowd (which I'm not sure I'm part of or not) would argue that the worries are overblown. Yes, one "instance" can be freely replaced by another at any point, without you knowing about it. But why would you care? Howe would you be able to tell? If you properly avoid using identity operations (which you were told not to), where is the problem? The objects are immutable, so proper equality testing will never get you the "wrong" logical behavior.
>>>
>>> The answer to this is generally "But… concurrency!". Which is why this is an ok place to chat about it probably. With no identity, how do you achieve atomic updates? Michael's MutableClock example (scroll down) of wanting to (potentially concurrently) add duration amounts to some notion of a point in time, while avoiding the potential for "losing" an add racy situations, requires some sort of synchronization. Since Instant is not mutable, and we are necessarily trying to atomically replace one Instant value with another, we have a problem with the notion that these values have no identity (and therefore no way to do a proper CAS on). We are also specifically admonished to not do any synchronization on "instances" of such classes, which should serious dissuade one from trying. Boxing is *an* answer (put the value in an instance that has a proper identity, and then CAS the identity), but a seemingly unsatisfying one...
>>>
>>> — Gil.
>>>
>>>> On Jul 6, 2017, at 11:47 AM, Justin Sampson <[hidden email]> wrote:
>>>>
>>>> That is absolutely horrifying, and leads me to believe we should not use such "value-based" classes at all in our code. Off I go to find a list of them and forbid them in my codebase. Somehow I thought that I was relatively up-to-date on my Java knowledge and this is the very first time I'm hearing about them. Surely the vast majority of Java programmers are similarly unaware, and the idea that an object instance can actually be replaced by another object instance at runtime is beyond surprising.
>>>>
>>>> -Justin
>>>>
>>>>
>>>> On 7/6/17, 10:49 AM, "Gil Tene" <[hidden email]> wrote:
>>>>
>>>> We are not discussing the upcoming value types. We are discussing the value-based classes as currently spec'ed in Java SE 8. Instant is a good example of such a class.
>>>>
>>>> To give you a feel for a currently valid (and may soon occur) optimization in Java 8: The current spec'ed behavior for Instant makes it possible to "inline" instances of Instant into their containing objects (which refer to them with mutable fields):
>>>> - There are no valid identity operations on Instant, so assignment can be validly done by copying contents onto the inlined version. A "get" of an inlined instance (where it can't be escape analyzed away) can be performed by returning a new (and different) instance of Instant.
>>>> - Word-tearing on value assignment [e.g. myClock.setInstsnt(Instant.now()))] can be avoided at least on some platforms, e.g. with 16-byte atomic operations, where the state of Instant instances can be represented in 16 bytes or less.
>>>>
>>>> This can then result in an elimination of a dereferencing operation when e.g. accessing someClock.getInstant().getNano(). (and no new instance will be created).
>>>>
>>>> Now the specific generics based containment below [AtomicReference<Instant>] may seem a bit more "challenging" (and likely will happen much later than in the non generic cases), but given the fact that the AtomicReference instance use is local to the MutableClock class and private, and no instances of that AtomicReference are exposed elsewhere, it would be valid to transform this code to use some custom subclass of AtomicReference that had  an Instant instance inlined in it. At that point, the updateAndGet operation comes into play. It may have "interesting" behavior because it is identity based, or (more likely) its existence could just prevent the whole optimization from occurring.
>>>>
>>>> In any case, to keep to well specified behavior, I'd box the Instant when putting it in an AtomicReference. That will provide you with a safe concurrent add() that doesn't use identity on Instant. You can probably do some simple caching on the get for speed (hold a cachedInstant field and a valid flag, re-read from boxed contents whenever invalid) with an invalidation (set invalid after each modification of the boxed contents) in set() and add().
>>>>
>>>> Oh, and BTW, you should probably check for null and enforce non-null for all incoming Instance arguments, e.g. in the constructor and in setInstance().
>>>>
>>>> Sent from my iPad
>>>>
>>>>> On Jul 6, 2017, at 9:01 AM, Justin Sampson <[hidden email]> wrote:
>>>>>
>>>>> Howdy,
>>>>>
>>>>> This thread got sidetracked with discussion of the upcoming "value types" in some later version of the JDK, which don't exist yet in 8, and really aren't relevant at all to Michael's question. He's asking about the existing Instant class, which is simply an immutable object with an equals() that compares its contents.
>>>>>
>>>>> It's absolutely silly to suggest that AtomicReference "doesn't work" for things like Instant. It simply uses identity instead of equals() in its operations, which is entirely well-defined.
>>>>>
>>>>> Michael's example MutableClock will work just fine. It uses updateAndGet(), which CAS's the result of the update. The point of the CAS is merely to check whether another thread has updated the reference concurrently, for which identity works correctly. The update is retried if the CAS fails, so there's no problem introduced by the fact that equals() for the value is different from equality.
>>>>>
>>>>> Cheers,
>>>>> Justin
>>>>>
>>>>>
>>>>> On 7/6/17, 7:31 AM, "Concurrency-interest on behalf of Michael Hixson" <[hidden email] on behalf of [hidden email]> wrote:
>>>>>
>>>>> Forwarding this reply of mine because I forgot to CC the mailing list.
>>>>>
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Michael Hixson <[hidden email]>
>>>>> Date: Thu, Jul 6, 2017 at 7:24 AM
>>>>> Subject: Re: [concurrency-interest] Should I avoid compareAndSet with
>>>>> value-based classes?
>>>>> To: Andrew Haley <[hidden email]>
>>>>>
>>>>>
>>>>>>>> On Thu, Jul 6, 2017 at 4:20 AM, Andrew Haley <[hidden email]> wrote:
>>>>>>>>> On 06/07/17 11:41, Alex Otenko wrote:
>>>>>>>>
>>>>>>>> On 6 Jul 2017, at 10:13, Andrew Haley <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> On 06/07/17 04:59, Michael Hixson wrote:
>>>>>>>>> AtomicReference and VarHandle are specified to use == in compareAndSet
>>>>>>>>> (and related) operations [1].  Using == to compare instances of
>>>>>>>>> value-based classes may lead to "unpredictable results" [2].  Does
>>>>>>>>> this mean I should avoid using compareAndSet with arguments that are
>>>>>>>>> instances of value-based classes?
>>>>>>>>>
>>>>>>>>> It seems like the documentation clearly tells me "yes, avoid doing
>>>>>>>>> that" but I'm hoping I misunderstood, or maybe AtomicReference and
>>>>>>>>> VarHandle are exempt somehow.  Otherwise, how do I implement
>>>>>>>>> non-broken compareAndSet and updateAndGet for a java.time.Instant
>>>>>>>>> value for example?
>>>>>>>>
>>>>>>>> java.time.Instant stores times that are longer than a JVM word, so
>>>>>>>> they cannot be CAS'd in a lock-free way unless a factory guarantees
>>>>>>>> that instances which compare equal also have the property of
>>>>>>>> reference equality.  j.t.Instant factories in the Java library are
>>>>>>>> explicitly documented *not* to have this property, so that doesn't
>>>>>>>> help.
>>>>>>>
>>>>>>> That’s not entirely clear.
>>>>>>>
>>>>>>> Wouldn’t this loop work:
>>>>>>>
>>>>>>> volatile j.t.Instant curr = ...
>>>>>>>
>>>>>>> j.t.Instant next = …
>>>>>>> j.t.Instant tmp = ...
>>>>>>> do {
>>>>>>> tmp = curr;
>>>>>>> if (tmp.equal(next)) break;
>>>>>>> } while(!curr.CAS(tmp, next));
>>>>>>>
>>>>>>> // assume curr is equal to next
>>>>>>
>>>>>> Something like that, yes.  But it's going to be evil if there are
>>>>>> several high-frequency writers.  If you're doing all that work in
>>>>>> order to CAS a timestamp, why not use a synchronized block?  It would
>>>>>> at least be less prone to the thundering herd, and we'd generate
>>>>>> pretty decent code for that.  It'd be interesting to compare and
>>>>>> contrast the two approaches for contended and non-contended cases.
>>>>>
>>>>> The main reason I reached for AtomicReference is that I thought, "I
>>>>> want thread-safe updates to this read-heavy value where writes won't
>>>>> get lost if there's contention -- this sounds like the sort of problem
>>>>> that java.util.concurrent.atomic solves."
>>>>>
>>>>> As a minor point, I wanted synchronization on reads to be as
>>>>> minor/invisible as possible, to affect the readers' behavior as little
>>>>> as possible (in comparison to their behavior when the value they're
>>>>> reading a constant value with no synchronization).
>>>>>
>>>>> But if AtomicReference is simply the wrong tool to use here, I
>>>>> shouldn't use it.  That's fine.
>>>>>
>>>>>>
>>>>>>>> If you want to be able to CAS a reference to a j.t.Instant, you're
>>>>>>>> going to have to wrap accesses to it in a synchronized block.  This is
>>>>>>>> a direct consequence of the JVM's inability to CAS multi-word objects.
>>>>>>>
>>>>>>> This is confusing.
>>>>>>>
>>>>>>> Surely this isn’t talking about CASing a reference? The contents of
>>>>>>> the object can’t be assumed to have any atomicity properties,
>>>>>>> whether it is j.t.Instant or not.
>>>>>>
>>>>>> I agree.  I'm trying to look at what the OP actually wants to do: I
>>>>>> assume this is some kind of atomic timestamp, and the OP wants to be
>>>>>> able to CAS an instance of j.u.Instant.
>>>>>
>>>>> It was more of a general worry and question.  Should I ever use
>>>>> AtomicReference with value-based classes?  It sounds like the answer
>>>>> is no.
>>>>>
>>>>> But here's some code that illustrates the specific problem I was
>>>>> trying to solve.  I think it "works" right now, but that it's in
>>>>> violation of the spec for value-based classes and so possibly not
>>>>> future-proof, and I think I understand how to fix it now.  Thanks for
>>>>> the tips.
>>>>>
>>>>>  class MutableClock {
>>>>>
>>>>>      static MutableClock create(Instant instant, ZoneId zone) {
>>>>>          return new MutableClock(
>>>>>                  new AtomicReference<>(instant),
>>>>>                  zone);
>>>>>      }
>>>>>
>>>>>      private final AtomicReference<Instant> instantHolder;
>>>>>      private final ZoneId zone;
>>>>>
>>>>>      private MutableClock(
>>>>>              AtomicReference<Instant> instantHolder,
>>>>>              ZoneId zone) {
>>>>>          this.instantHolder = instantHolder;
>>>>>          this.zone = zone;
>>>>>      }
>>>>>
>>>>>      Instant instant() {
>>>>>          return instantHolder.get();
>>>>>      }
>>>>>
>>>>>      ZoneId getZone() {
>>>>>          return zone;
>>>>>      }
>>>>>
>>>>>      void setInstant(Instant newInstant) {
>>>>>          instantHolder.set(newInstant);
>>>>>      }
>>>>>
>>>>>      void add(Duration amountToAdd) {
>>>>>          // this is the part that uses == and CAS
>>>>>          instantHolder.updateAndGet(
>>>>>                instant -> instant.plus(amountToAdd));
>>>>>      }
>>>>>
>>>>>      MutableClock withZone(ZoneId newZone) {
>>>>>          // conveniently, AtomicReference also acts as a
>>>>>          // vehicle for "shared updates" between instances
>>>>>          // of my class
>>>>>          return new MutableClock(instantHolder, newZone);
>>>>>      }
>>>>>  }
>>>>>
>>>>> -Michael
>>>>> _______________________________________________
>>>>> Concurrency-interest mailing list
>>>>> [hidden email]
>>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Concurrency-interest mailing list
>>>>> [hidden email]
>>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> [hidden email]
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Gregg Wonderly-3
In reply to this post by Justin Sampson
So you are suggesting that I can’t create two different Instant objects and compare them with identity == on a third object which references one of those instances as a form of decision logic?   Why in the world would you want to break Java in that way?

Gregg


> On Jul 6, 2017, at 2:12 PM, Gil Tene <[hidden email]> wrote:
>
> The "it's not as horrifying as you might think" crowd (which I'm not sure I'm part of or not) would argue that the worries are overblown. Yes, one "instance" can be freely replaced by another at any point, without you knowing about it. But why would you care? Howe would you be able to tell? If you properly avoid using identity operations (which you were told not to), where is the problem? The objects are immutable, so proper equality testing will never get you the "wrong" logical behavior.
>
> The answer to this is generally "But… concurrency!". Which is why this is an ok place to chat about it probably. With no identity, how do you achieve atomic updates? Michael's MutableClock example (scroll down) of wanting to (potentially concurrently) add duration amounts to some notion of a point in time, while avoiding the potential for "losing" an add racy situations, requires some sort of synchronization. Since Instant is not mutable, and we are necessarily trying to atomically replace one Instant value with another, we have a problem with the notion that these values have no identity (and therefore no way to do a proper CAS on). We are also specifically admonished to not do any synchronization on "instances" of such classes, which should serious dissuade one from trying. Boxing is *an* answer (put the value in an instance that has a proper identity, and then CAS the identity), but a seemingly unsatisfying one...
>
> — Gil.
>
>> On Jul 6, 2017, at 11:47 AM, Justin Sampson <[hidden email]> wrote:
>>
>> That is absolutely horrifying, and leads me to believe we should not use such "value-based" classes at all in our code. Off I go to find a list of them and forbid them in my codebase. Somehow I thought that I was relatively up-to-date on my Java knowledge and this is the very first time I'm hearing about them. Surely the vast majority of Java programmers are similarly unaware, and the idea that an object instance can actually be replaced by another object instance at runtime is beyond surprising.
>>
>> -Justin
>>
>>
>> On 7/6/17, 10:49 AM, "Gil Tene" <[hidden email]> wrote:
>>
>> We are not discussing the upcoming value types. We are discussing the value-based classes as currently spec'ed in Java SE 8. Instant is a good example of such a class.
>>
>> To give you a feel for a currently valid (and may soon occur) optimization in Java 8: The current spec'ed behavior for Instant makes it possible to "inline" instances of Instant into their containing objects (which refer to them with mutable fields):
>> - There are no valid identity operations on Instant, so assignment can be validly done by copying contents onto the inlined version. A "get" of an inlined instance (where it can't be escape analyzed away) can be performed by returning a new (and different) instance of Instant.
>> - Word-tearing on value assignment [e.g. myClock.setInstsnt(Instant.now()))] can be avoided at least on some platforms, e.g. with 16-byte atomic operations, where the state of Instant instances can be represented in 16 bytes or less.
>>
>> This can then result in an elimination of a dereferencing operation when e.g. accessing someClock.getInstant().getNano(). (and no new instance will be created).
>>
>> Now the specific generics based containment below [AtomicReference<Instant>] may seem a bit more "challenging" (and likely will happen much later than in the non generic cases), but given the fact that the AtomicReference instance use is local to the MutableClock class and private, and no instances of that AtomicReference are exposed elsewhere, it would be valid to transform this code to use some custom subclass of AtomicReference that had  an Instant instance inlined in it. At that point, the updateAndGet operation comes into play. It may have "interesting" behavior because it is identity based, or (more likely) its existence could just prevent the whole optimization from occurring.
>>
>> In any case, to keep to well specified behavior, I'd box the Instant when putting it in an AtomicReference. That will provide you with a safe concurrent add() that doesn't use identity on Instant. You can probably do some simple caching on the get for speed (hold a cachedInstant field and a valid flag, re-read from boxed contents whenever invalid) with an invalidation (set invalid after each modification of the boxed contents) in set() and add().
>>
>> Oh, and BTW, you should probably check for null and enforce non-null for all incoming Instance arguments, e.g. in the constructor and in setInstance().
>>
>> Sent from my iPad
>>
>>> On Jul 6, 2017, at 9:01 AM, Justin Sampson <[hidden email]> wrote:
>>>
>>> Howdy,
>>>
>>> This thread got sidetracked with discussion of the upcoming "value types" in some later version of the JDK, which don't exist yet in 8, and really aren't relevant at all to Michael's question. He's asking about the existing Instant class, which is simply an immutable object with an equals() that compares its contents.
>>>
>>> It's absolutely silly to suggest that AtomicReference "doesn't work" for things like Instant. It simply uses identity instead of equals() in its operations, which is entirely well-defined.
>>>
>>> Michael's example MutableClock will work just fine. It uses updateAndGet(), which CAS's the result of the update. The point of the CAS is merely to check whether another thread has updated the reference concurrently, for which identity works correctly. The update is retried if the CAS fails, so there's no problem introduced by the fact that equals() for the value is different from equality.
>>>
>>> Cheers,
>>> Justin
>>>
>>>
>>> On 7/6/17, 7:31 AM, "Concurrency-interest on behalf of Michael Hixson" <[hidden email] on behalf of [hidden email]> wrote:
>>>
>>> Forwarding this reply of mine because I forgot to CC the mailing list.
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Michael Hixson <[hidden email]>
>>> Date: Thu, Jul 6, 2017 at 7:24 AM
>>> Subject: Re: [concurrency-interest] Should I avoid compareAndSet with
>>> value-based classes?
>>> To: Andrew Haley <[hidden email]>
>>>
>>>
>>>>>> On Thu, Jul 6, 2017 at 4:20 AM, Andrew Haley <[hidden email]> wrote:
>>>>>>> On 06/07/17 11:41, Alex Otenko wrote:
>>>>>>
>>>>>> On 6 Jul 2017, at 10:13, Andrew Haley <[hidden email]> wrote:
>>>>>>
>>>>>> On 06/07/17 04:59, Michael Hixson wrote:
>>>>>>> AtomicReference and VarHandle are specified to use == in compareAndSet
>>>>>>> (and related) operations [1].  Using == to compare instances of
>>>>>>> value-based classes may lead to "unpredictable results" [2].  Does
>>>>>>> this mean I should avoid using compareAndSet with arguments that are
>>>>>>> instances of value-based classes?
>>>>>>>
>>>>>>> It seems like the documentation clearly tells me "yes, avoid doing
>>>>>>> that" but I'm hoping I misunderstood, or maybe AtomicReference and
>>>>>>> VarHandle are exempt somehow.  Otherwise, how do I implement
>>>>>>> non-broken compareAndSet and updateAndGet for a java.time.Instant
>>>>>>> value for example?
>>>>>>
>>>>>> java.time.Instant stores times that are longer than a JVM word, so
>>>>>> they cannot be CAS'd in a lock-free way unless a factory guarantees
>>>>>> that instances which compare equal also have the property of
>>>>>> reference equality.  j.t.Instant factories in the Java library are
>>>>>> explicitly documented *not* to have this property, so that doesn't
>>>>>> help.
>>>>>
>>>>> That’s not entirely clear.
>>>>>
>>>>> Wouldn’t this loop work:
>>>>>
>>>>> volatile j.t.Instant curr = ...
>>>>>
>>>>> j.t.Instant next = …
>>>>> j.t.Instant tmp = ...
>>>>> do {
>>>>> tmp = curr;
>>>>> if (tmp.equal(next)) break;
>>>>> } while(!curr.CAS(tmp, next));
>>>>>
>>>>> // assume curr is equal to next
>>>>
>>>> Something like that, yes.  But it's going to be evil if there are
>>>> several high-frequency writers.  If you're doing all that work in
>>>> order to CAS a timestamp, why not use a synchronized block?  It would
>>>> at least be less prone to the thundering herd, and we'd generate
>>>> pretty decent code for that.  It'd be interesting to compare and
>>>> contrast the two approaches for contended and non-contended cases.
>>>
>>> The main reason I reached for AtomicReference is that I thought, "I
>>> want thread-safe updates to this read-heavy value where writes won't
>>> get lost if there's contention -- this sounds like the sort of problem
>>> that java.util.concurrent.atomic solves."
>>>
>>> As a minor point, I wanted synchronization on reads to be as
>>> minor/invisible as possible, to affect the readers' behavior as little
>>> as possible (in comparison to their behavior when the value they're
>>> reading a constant value with no synchronization).
>>>
>>> But if AtomicReference is simply the wrong tool to use here, I
>>> shouldn't use it.  That's fine.
>>>
>>>>
>>>>>> If you want to be able to CAS a reference to a j.t.Instant, you're
>>>>>> going to have to wrap accesses to it in a synchronized block.  This is
>>>>>> a direct consequence of the JVM's inability to CAS multi-word objects.
>>>>>
>>>>> This is confusing.
>>>>>
>>>>> Surely this isn’t talking about CASing a reference? The contents of
>>>>> the object can’t be assumed to have any atomicity properties,
>>>>> whether it is j.t.Instant or not.
>>>>
>>>> I agree.  I'm trying to look at what the OP actually wants to do: I
>>>> assume this is some kind of atomic timestamp, and the OP wants to be
>>>> able to CAS an instance of j.u.Instant.
>>>
>>> It was more of a general worry and question.  Should I ever use
>>> AtomicReference with value-based classes?  It sounds like the answer
>>> is no.
>>>
>>> But here's some code that illustrates the specific problem I was
>>> trying to solve.  I think it "works" right now, but that it's in
>>> violation of the spec for value-based classes and so possibly not
>>> future-proof, and I think I understand how to fix it now.  Thanks for
>>> the tips.
>>>
>>>   class MutableClock {
>>>
>>>       static MutableClock create(Instant instant, ZoneId zone) {
>>>           return new MutableClock(
>>>                   new AtomicReference<>(instant),
>>>                   zone);
>>>       }
>>>
>>>       private final AtomicReference<Instant> instantHolder;
>>>       private final ZoneId zone;
>>>
>>>       private MutableClock(
>>>               AtomicReference<Instant> instantHolder,
>>>               ZoneId zone) {
>>>           this.instantHolder = instantHolder;
>>>           this.zone = zone;
>>>       }
>>>
>>>       Instant instant() {
>>>           return instantHolder.get();
>>>       }
>>>
>>>       ZoneId getZone() {
>>>           return zone;
>>>       }
>>>
>>>       void setInstant(Instant newInstant) {
>>>           instantHolder.set(newInstant);
>>>       }
>>>
>>>       void add(Duration amountToAdd) {
>>>           // this is the part that uses == and CAS
>>>           instantHolder.updateAndGet(
>>>                 instant -> instant.plus(amountToAdd));
>>>       }
>>>
>>>       MutableClock withZone(ZoneId newZone) {
>>>           // conveniently, AtomicReference also acts as a
>>>           // vehicle for "shared updates" between instances
>>>           // of my class
>>>           return new MutableClock(instantHolder, newZone);
>>>       }
>>>   }
>>>
>>> -Michael
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> [hidden email]
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> [hidden email]
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Gregg Wonderly-3
In reply to this post by Gil Tene-2
Factories have the right to decide which instance to return, but once I have an instance, identity should still apply from that point forward.  A developer will read some documentation about random return values, but you are talking about a new language if a reference ever changes identity in Java.

Gregg

> On Jul 6, 2017, at 4:29 PM, Stephen Colebourne <[hidden email]> wrote:
>
> Given:
>
> Instant i1 = Instant.ofEpochMilli(2);
> Instant i2 = Instant.ofEpochMilli(2);
>
> In Java 8:
>
> i1.equals(i2) is true
> i1 == i2  is false
>
> And in some future version, i1 == i2  might be true.
>
> But this is not especially radical. Java 10 could introduce a cache in
> the factory method that always returns the same instance. In fact,
> there already is a cache if you call
> Instant.ofEpochMilli(0);
>
> The key phrase in
> http://download.java.net/java/jdk9/docs/api/java/lang/doc-files/ValueBased.html
> is "A program may produce unpredictable results if it attempts to
> distinguish two references to equal values of a value-based class".
> IMO, the intent is to tell everyone that they shouldn't try to tell
> the difference between two instances using ==, and if they do their
> program may change meaning in the future (ie. be unpredictable, but
> not stupidly unpredictable as some in the thread are suggesting).
>
> Stephen
>
>
> On 6 July 2017 at 17:33, Gil Tene <[hidden email]> wrote:
>>
>> It says: "Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects and should be avoided." It does not say what the reason for the unpredictable effect may be and WHEN you shouldn't use identity based operations, it warns you not to use them for any reason whatsoever. Can't be much more clear than that, and you don't need to be a JVM or compiler implementor to understand it. It means "don't do that". And "if you do that, very surprising things may (or may not) happen".
>>
>> Acting on a current understanding and perception of what implementations actually do, and saying "I thought that what it really means is that using identity in some way X would be unreliable because of effect Y, but using identity in case Z is ok, because I don't see why it shouldn't be" is a wrong reading of this clear admonition to not use identity for anything. Doing so will come back to bite you, either now or in the future.
>>
>> For example, instances of value-based classes have the [well documented] quality of being "freely substitutable when equal, meaning that interchanging any two instances x and y that are equal according to equals() in any computation or method invocation should produce no visible change in behavior." The JVM may (and likely will at some point will) use this quality freely in some optimizations, A simple and obviously valid resulting optimization would be for == to always be evaluated as false when the operands are instances of value-based classes: since the JVM *may* freely substitute the instances of either side of the == evaluation with some instance that is equal according to equals(), it can choose to do so in all evaluations of ==, which would mean that the two sides are never the same instance, and would then mean that the JVM can treat all code that would only execute if == were true as dead code. Similarly, != may trivially be evaluated as always-true. And since these optimizations may or may not be applied in different places and times, they may lead to seemingly random evaluation of == or != for identical code on identical data (for the exact same, unmodified values of a and d, a will sometimes be equal to d and sometimes not, and at the same point in code, depending on mood).
>>
>> We could further discuss whether or not the JVM is allowed to "falsely" indicate that == is true (or that != is false) even when the instances differ in value (so are not .equals()). It is. Doing that may certainly surprise anyone who uses the identity based == for anything to do with instances of value-based classes, even tho using it would be silly given that == might obviously be always-false. For example, I could see how someone may mistakenly try to use == as an "optimization" on the assumption that if they get lucky and == is true, .equals() must be true as well, and that evaluating == might be cheaper, but they would still "do the right thing" in the != case. But that would be a mistake, and a clear violation of the "don't do that" admonition above. The cases where the result of == can be *unpredictable* are not limited to cases where the JVM freely substitutes instances for other equal() ones, that's just one example of how the JVM may obviously and validly use one known quality of value-based classes. But another key quality of instances of value based classes is that they "are considered equal solely based on equals(), not based on reference equality (==)". There is nothing there that limits us to "if == is true, equals() must be true as well". It may be convenient to think otherwise when wanting to explain how breaking the rules in some specific way is still ok (and currently seems to work). But it's not. Bottom line: The JVM *may* choose to make == always-true. Nothing wrong with that.
>>
>> It is dangerous (and nearly impossible) to deduce which optimizations may or may not happen when they are clearly allowed by the specified set of rules and qualities. The defined qualities are what matter, and optimizations that indirectly result from the propagation of those qualities are allowed and may (or may  not) happen. Instance identity either exists or doesn't, and instance Identity checks either have meaning, or they don't. If they do, certain things follow (like .equals() always being true if the identity of the twin instances is the same, as tested by ==). If they don't, then identity checks are meaningless, and can be discarded or conveniently evaluated in ways that seem profitable.
>>
>> For "instances" of value-based classes, instance identity does not exist. Unfortunately, unlike value types, where the operand == is defined to act on value and not on identity, the operand == is undefined for instances of value-based classes. It certainly does not mean "if true, the identity of these things is the same", and it certainly doesn't mean "if false, these things are not equal". But it also doesn't mean "if true, these things are equal". It is *undefined*, specified with "may have unpredictable effects", and users are clearly told not to use it for anything.
>>
>> One can argue that the spec should change, e.g. add a statement that would have the effect of requiring "if == is true then .equals() is also true", and would prevent or limit certain unpredictable effects when considering the identity of identity-less things, but I suspect that writing that down in actual words would be painful given the necessary "there is no meaning to identify, but..." logic. We could also look to redefine the meaning of certain operands, e.g. == and != can be dealt with as they are in value types, but compare in compareAndSet is more challenging...
>>
>> This is [partly] why I think that throwing an exception (or even a compile-time error where possible) when encountering == or != operations (and any of the other undefined behavior ones) on instances of value-based classes is a good idea, and something that should start happening ASAP. Any such operation is wrong (literally) by definition, and the "may have unpredictable effects" statement in the spec is certainly wide enough to allow exception throwing. It is wide enough to allow much worse things to happen, and silent unpredictable and undefined behavior, while allowed, is worse than preventing the code from executing. The same way we wouldn't argue that synchronized(int) should simply be "undefined" but silently allowed to run with unpredictable effects, we shouldn't argue that synchronized(LocalDateTime) should.
>>
>> Sent from my iPad
>>
>> On Jul 6, 2017, at 3:04 AM, Alex Otenko <[hidden email]> wrote:
>>
>> :-) the one causing Byzantine failures!
>>
>> Given how underspecified the things generally are, and that the target audience of such javadoc is not a JVM implementor, we shouldn’t read too much into the possible freedoms the vague wording seems to imply. It shouldn’t suddenly break the promises about identity equality for specific instances.
>>
>> All it’s saying is that, like Integer.from(10) may or may not return the same instance. It may or may not work the same way throughout the JVM’s lifetime, allowing the implementors to choose suitable caching strategies, code optimizations, etc - therefore should not rely on comparing identities, and such; for example, synchronized(Integer.from(10)) does not guarantee neither lock freedom, nor deadlock freedom. It should not say that suddenly it is unsafe to compare identities (like Gil suggests JVM could start throwing exceptions). It should not say that suddenly we shouldn’t be able to CAS (like Gil says suddenly the reference to instance can sneakily be replaced with something else).
>>
>>
>> Alex
>>
>>
>> On 6 Jul 2017, at 10:12, Millies, Sebastian <[hidden email]> wrote:
>>
>> just out of curiosity: I am familiar with the term “Byzantine failure”, but what is a “Byzantine optimization”?
>> n  Sebastian
>>
>> From: Concurrency-interest [mailto:[hidden email]] On Behalf Of Alex Otenko
>> Sent: Thursday, July 06, 2017 10:17 AM
>> To: Gil Tene
>> Cc: [hidden email]
>> Subject: Re: [concurrency-interest] Should I avoid compareAndSet with value-based classes?
>>
>>
>>
>> On 6 Jul 2017, at 08:47, Gil Tene <[hidden email]> wrote:
>>
>>
>>
>> Sent from my iPad
>>
>>
>> On Jul 6, 2017, at 12:38 AM, Alex Otenko <[hidden email]> wrote:
>>
>> All it is saying is:
>>
>> LocalDateTime a = LocalDateTime.parse("2007-12-03T10:15:30");
>> LocalDateTime b = LocalDateTime.parse("2007-12-03T10:15:30");
>> LocalDateTime c = LocalDateTime.parse("2007-12-03T10:15:30");
>>
>> a==b && b==c can be true and can be false
>>
>>
>> It also means that even when:
>>
>> LocalDateTime d = a;
>> ...
>> (a == d) may or may not be true. And may change whether it is true or not at any time,
>>
>>
>> I meant an even stronger assertion:
>>
>> assert (a==b) == (b==a) : "No Byzantine optimizations"
>> assert (a==d) == (a==d): “No Byzantine optimizations"
>>
>> Alex
>>
>>
>>
>>
>>
>>
>> Alex
>>
>>
>> On 6 Jul 2017, at 08:28, Gil Tene <[hidden email]> wrote:
>>
>>
>>
>> Sent from my iPad
>>
>>
>> On Jul 5, 2017, at 11:51 PM, Henrik Johansson <[hidden email]> wrote:
>>
>> Oh, without having followed the value type discussions I think it was a mistake to not "fix" equality. Why not make it a deep comparison if the reference is different? If it points to the same object we are done otherwise start checking the struct content.
>> There may be a lot I missed here but a new type of object could be allowed to have different meaning equality. Right?
>>
>> .equals() means what you want it to mean. == and != (and the compare in compareAndSet) mean very specific things, and cannot be overridden.
>>
>> For non-reference value types (int, long, char, etc.), == and != are value comparisons. An int has no identity. Just a value:
>> int a = 5;
>> int b = 5;
>> boolean y = (a == b);  // true
>>
>> For references to instances of (non value-based) classes, == and != can be thought of as comparing the value of the reference (and not the contents of the object instances). This is an identity comparison, which ignores values within the object:
>> Integer a = new Integer(5);
>> Integer b = new Integer(5);
>> boolean x = a.equals(b);   // true
>> boolean y = (a == b);   // false
>>
>> And for references to value-based classes (which is a relatively new thing, but is part of Java 8), the meaning of == and != appears to be undefined. E.g.:
>>
>> LocalDateTime a = LocalDateTime.parse("2007-12-03T10:15:30");
>> LocalDateTime b = LocalDateTime.parse("2007-12-03T10:15:30");
>> boolean x = a.equals(b);   // true
>> boolean y = (a == b);   // unpredictable, undefined, who knows.
>>                                       // Could be true, could be false.
>>                                       // Could theoretically change the values of a or b, or of something else
>>
>>
>>
>>
>> On Thu, 6 Jul 2017, 07:12 Gil Tene, <[hidden email]> wrote:
>>
>>
>> I'd take that documentation seriously. It basically says that ==, !=, synchronization, identity hashing, and serialization are undefined behaviors.
>>
>> While the *current* implementations may carry some semi-intuitive behvaiors, e.g. where == indicates true when comparing two references to instances of a value-based class where the value of the references is the same, there is no guarantee that at some point in the [near or far] future that behavior will remain. Specifically, attempting == (or !=, or synchronization, etc., including compareAndSet) on a reference to a value based class is allowed to do ANYTHING in the future.
>> For example:
>> - It may throw an exception (something it should probably start doing ASAP to avoid future surprises).
>> - It may return always-false, even when the two references are "to the same instance" (and probably will, through many possible value-based compiler optimizations that will erase the unneeded notion of reference and identity).
>> - It may overwrite random locations in memory or to variables that the code performing the operation has the privilege to write to (which it probably shouldn't, but that's certainly included in what "undefined" and "unpredictable effects" can mean).
>> - It may sometimes do one of the above, and sometimes seem to be doing what you mean it to do. Switching between modes on a whim (e.g. when a tier 2 optimizing compilation is applied, or when the mutton is nice and lean and the tomato is ripe).
>>
>> So no, there is no way for compareAndSet to work "correctly" on a reference to an instance of a value-based class. Even if it happens to appear to work "correctly" now, expect it to blow up in bad and potentially silent ways in the future.
>>
>> — Gil.
>>
>>> On Jul 5, 2017, at 9:47 PM, Brian S O'Neill <[hidden email]> wrote:
>>>
>>> I think the wording in the value-based document is too strong. It's perfectly fine to compare value based instances using ==, but it can lead to confusing results when comparing distinct instances with equivalent state. Using compareAndSet with a box isn't necessary for it to work "correctly" with a value-based class.
>>>
>>> By "correctly", I mean the compareAndSet operation works correctly, using == comparison. However, if your intention is for compareAndSet to compare Instants based on their state, then this of course won't work properly.
>>>
>>> If you want to perform a compareAndSet for an Instant's state (time since epoch), then you need to use something that can be compared atomically. This means the state must be representable in a 64-bit value or smaller. The Instant class measures time using a 64-bit long and a 32-bit int, and so this state cannot be compared atomically. You'd have to chop off some precision or use something else.
>>>
>>>
>>> On 2017-07-05 09:20 PM, Gil Tene wrote:
>>>> Reference equality for value based classes (as referenced below) lacks meaning, as there is no notion of identity in such classes (only a notion of value). And since compareAndSet on reference fields is basically an idenitity-based operation [in the compare part], the two won't mix well logically.
>>>> Specifically, while two references to e.g. java.time.LocalDateTime instances being == to each other *probably* means that the two are actually equal in value, the opposite is not true: Being != to each other does NOT mean that they are logically different. As such, the "compare" part in compareAndSet may falsely fail even when the two instances are logically equal to each other, leaving the rest of your logic potentially exposed.
>>>> Bottom line: given the explicit warning to not use == and != on references to value-based instances, I'd avoid using compareAndSet on those references. If you really need to use a value-based class in your logic, consider boxing it in another object that has [normal] identity.
>>>> — Gil.
>>>>> On Jul 5, 2017, at 8:59 PM, Michael Hixson <[hidden email]> wrote:
>>>>>
>>>>> AtomicReference and VarHandle are specified to use == in compareAndSet
>>>>> (and related) operations [1].  Using == to compare instances of
>>>>> value-based classes may lead to "unpredictable results" [2].  Does
>>>>> this mean I should avoid using compareAndSet with arguments that are
>>>>> instances of value-based classes?
>>>>>
>>>>> It seems like the documentation clearly tells me "yes, avoid doing
>>>>> that" but I'm hoping I misunderstood, or maybe AtomicReference and
>>>>> VarHandle are exempt somehow.  Otherwise, how do I implement
>>>>> non-broken compareAndSet and updateAndGet for a java.time.Instant
>>>>> value for example?  Do I have to box the value in something that's not
>>>>> a value-based class first, like AtomicReference<Box<Instant>>?
>>>>>
>>>>> -Michael
>>>>>
>>>>> [1] http://download.java.net/java/jdk9/docs/api/java/util/concurrent/atomic/AtomicReference.html#compareAndSet-V-V-
>>>>> [2] http://download.java.net/java/jdk9/docs/api/java/lang/doc-files/ValueBased.html
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> [hidden email]
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>>
>>
>>
>> Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany – Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Gregg Wonderly-3
In reply to this post by Alex Otenko
Anything that is a Number should be performing automatic unboxing to perform literal value comparisons.  I count on this day in and day out.  There is no reason that Number values should ever do anything different.   You can suggest that two Number values which might be typed as Object parameters into a code structure that compares them with ==, will be costly to execute because of runtime type checking.  But, if the developer codes it that way, because they have other Object values which are used in identity comparisons that are logically valid for the code structure, why perform a compile time optimization that invalidates the premise of how identity works against auto-boxing/unboxing?

Gregg

On Jul 6, 2017, at 12:52 PM, Gil Tene <[hidden email]> wrote:

Hence my suggestion that identity-based operations on instances of value-based classes should throw exceptions... Right now they silently do unpredictable things, and should be avoided in any case (but harder to know/find when you accidentally use them).

Sent from my iPad

On Jul 6, 2017, at 10:46 AM, Alex Otenko <[hidden email]> wrote:

Are they subclasses of Object or not? If they are not, no questions. If they are, someone still needs to explain how exactly the “identity based operations” can be avoided safely.

List<j.u.Optional> is just a List underneath, and searching for an item may use “identity based operations”, whether you want it or not - depending on what implementation of List you happen to use.

Alex

On 6 Jul 2017, at 17:33, Gil Tene <[hidden email]> wrote:

It says: "Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects and should be avoided." It does not say what the reason for the unpredictable effect may be and WHEN you shouldn't use identity based operations, it warns you not to use them for any reason whatsoever. Can't be much more clear than that, and you don't need to be a JVM or compiler implementor to understand it. It means "don't do that". And "if you do that, very surprising things may (or may not) happen". 

Acting on a current understanding and perception of what implementations actually do, and saying "I thought that what it really means is that using identity in some way X would be unreliable because of effect Y, but using identity in case Z is ok, because I don't see why it shouldn't be" is a wrong reading of this clear admonition to not use identity for anything. Doing so will come back to bite you, either now or in the future.

For example, instances of value-based classes have the [well documented] quality of being "freely substitutable when equal, meaning that interchanging any two instances x and y that are equal according to equals() in any computation or method invocation should produce no visible change in behavior." The JVM may (and likely will at some point will) use this quality freely in some optimizations, A simple and obviously valid resulting optimization would be for == to always be evaluated as false when the operands are instances of value-based classes: since the JVM *may* freely substitute the instances of either side of the == evaluation with some instance that is equal according to equals(), it can choose to do so in all evaluations of ==, which would mean that the two sides are never the same instance, and would then mean that the JVM can treat all code that would only execute if == were true as dead code. Similarly, != may trivially be evaluated as always-true. And since these optimizations may or may not be applied in different places and times, they may lead to seemingly random evaluation of == or != for identical code on identical data (for the exact same, unmodified values of a and d, a will sometimes be equal to d and sometimes not, and at the same point in code, depending on mood).

We could further discuss whether or not the JVM is allowed to "falsely" indicate that == is true (or that != is false) even when the instances differ in value (so are not .equals()). It is. Doing that may certainly surprise anyone who uses the identity based == for anything to do with instances of value-based classes, even tho using it would be silly given that == might obviously be always-false. For example, I could see how someone may mistakenly try to use == as an "optimization" on the assumption that if they get lucky and == is true, .equals() must be true as well, and that evaluating == might be cheaper, but they would still "do the right thing" in the != case. But that would be a mistake, and a clear violation of the "don't do that" admonition above. The cases where the result of == can be *unpredictable* are not limited to cases where the JVM freely substitutes instances for other equal() ones, that's just one example of how the JVM may obviously and validly use one known quality of value-based classes. But another key quality of instances of value based classes is that they "are considered equal solely based on equals(), not based on reference equality (==)". There is nothing there that limits us to "if == is true, equals() must be true as well". It may be convenient to think otherwise when wanting to explain how breaking the rules in some specific way is still ok (and currently seems to work). But it's not. Bottom line: The JVM *may* choose to make == always-true. Nothing wrong with that.

It is dangerous (and nearly impossible) to deduce which optimizations may or may not happen when they are clearly allowed by the specified set of rules and qualities. The defined qualities are what matter, and optimizations that indirectly result from the propagation of those qualities are allowed and may (or may  not) happen. Instance identity either exists or doesn't, and instance Identity checks either have meaning, or they don't. If they do, certain things follow (like .equals() always being true if the identity of the twin instances is the same, as tested by ==). If they don't, then identity checks are meaningless, and can be discarded or conveniently evaluated in ways that seem profitable.

For "instances" of value-based classes, instance identity does not exist. Unfortunately, unlike value types, where the operand == is defined to act on value and not on identity, the operand == is undefined for instances of value-based classes. It certainly does not mean "if true, the identity of these things is the same", and it certainly doesn't mean "if false, these things are not equal". But it also doesn't mean "if true, these things are equal". It is *undefined*, specified with "may have unpredictable effects", and users are clearly told not to use it for anything.

One can argue that the spec should change, e.g. add a statement that would have the effect of requiring "if == is true then .equals() is also true", and would prevent or limit certain unpredictable effects when considering the identity of identity-less things, but I suspect that writing that down in actual words would be painful given the necessary "there is no meaning to identify, but..." logic. We could also look to redefine the meaning of certain operands, e.g. == and != can be dealt with as they are in value types, but compare in compareAndSet is more challenging...

This is [partly] why I think that throwing an exception (or even a compile-time error where possible) when encountering == or != operations (and any of the other undefined behavior ones) on instances of value-based classes is a good idea, and something that should start happening ASAP. Any such operation is wrong (literally) by definition, and the "may have unpredictable effects" statement in the spec is certainly wide enough to allow exception throwing. It is wide enough to allow much worse things to happen, and silent unpredictable and undefined behavior, while allowed, is worse than preventing the code from executing. The same way we wouldn't argue that synchronized(int) should simply be "undefined" but silently allowed to run with unpredictable effects, we shouldn't argue that synchronized(LocalDateTime) should.

Sent from my iPad

On Jul 6, 2017, at 3:04 AM, Alex Otenko <[hidden email]> wrote:

:-) the one causing Byzantine failures!

Given how underspecified the things generally are, and that the target audience of such javadoc is not a JVM implementor, we shouldn’t read too much into the possible freedoms the vague wording seems to imply. It shouldn’t suddenly break the promises about identity equality for specific instances.

All it’s saying is that, like Integer.from(10) may or may not return the same instance. It may or may not work the same way throughout the JVM’s lifetime, allowing the implementors to choose suitable caching strategies, code optimizations, etc - therefore should not rely on comparing identities, and such; for example, synchronized(Integer.from(10)) does not guarantee neither lock freedom, nor deadlock freedom. It should not say that suddenly it is unsafe to compare identities (like Gil suggests JVM could start throwing exceptions). It should not say that suddenly we shouldn’t be able to CAS (like Gil says suddenly the reference to instance can sneakily be replaced with something else).


Alex


On 6 Jul 2017, at 10:12, Millies, Sebastian <[hidden email]> wrote:

just out of curiosity: I am familiar with the term “Byzantine failure”, but what is a “Byzantine optimization”?
n  Sebastian
 
From: Concurrency-interest [[hidden email]] On Behalf Of Alex Otenko
Sent: Thursday, July 06, 2017 10:17 AM
To: Gil Tene
Cc: [hidden email]
Subject: Re: [concurrency-interest] Should I avoid compareAndSet with value-based classes?
 
 
On 6 Jul 2017, at 08:47, Gil Tene <[hidden email]> wrote:
 


Sent from my iPad


On Jul 6, 2017, at 12:38 AM, Alex Otenko <[hidden email]> wrote:

All it is saying is:
 
  LocalDateTime a = LocalDateTime.parse("2007-12-03T10:15:30");
  LocalDateTime b = LocalDateTime.parse("2007-12-03T10:15:30");
  LocalDateTime c = LocalDateTime.parse("2007-12-03T10:15:30");
 
a==b && b==c can be true and can be false
 
It also means that even when:
 
  LocalDateTime d = a;
  ...
  (a == d) may or may not be true. And may change whether it is true or not at any time,
 
I meant an even stronger assertion:
 
assert (a==b) == (b==a) : "No Byzantine optimizations"
assert (a==d) == (a==d): “No Byzantine optimizations"
 
Alex
 


 
 
Alex
 
On 6 Jul 2017, at 08:28, Gil Tene <[hidden email]> wrote:
 


Sent from my iPad


On Jul 5, 2017, at 11:51 PM, Henrik Johansson <[hidden email]> wrote:

Oh, without having followed the value type discussions I think it was a mistake to not "fix" equality. Why not make it a deep comparison if the reference is different? If it points to the same object we are done otherwise start checking the struct content. 
There may be a lot I missed here but a new type of object could be allowed to have different meaning equality. Right?
.equals() means what you want it to mean. == and != (and the compare in compareAndSet) mean very specific things, and cannot be overridden.
 
For non-reference value types (int, long, char, etc.), == and != are value comparisons. An int has no identity. Just a value:
  int a = 5;
  int b = 5;
  boolean y = (a == b);  // true
 
For references to instances of (non value-based) classes, == and != can be thought of as comparing the value of the reference (and not the contents of the object instances). This is an identity comparison, which ignores values within the object:
  Integer a = new Integer(5);
  Integer b = new Integer(5);
  boolean x = a.equals(b);   // true
  boolean y = (a == b);   // false
 
And for references to value-based classes (which is a relatively new thing, but is part of Java 8), the meaning of == and != appears to be undefined. E.g.:
 
  LocalDateTime a = LocalDateTime.parse("2007-12-03T10:15:30");
  LocalDateTime b = LocalDateTime.parse("2007-12-03T10:15:30");
  boolean x = a.equals(b);   // true
  boolean y = (a == b);   // unpredictable, undefined, who knows. 
                                         // Could be true, could be false.
                                         // Could theoretically change the values of a or b, or of something else
 


 
On Thu, 6 Jul 2017, 07:12 Gil Tene, <[hidden email]> wrote:

I'd take that documentation seriously. It basically says that ==, !=, synchronization, identity hashing, and serialization are undefined behaviors.

While the *current* implementations may carry some semi-intuitive behvaiors, e.g. where == indicates true when comparing two references to instances of a value-based class where the value of the references is the same, there is no guarantee that at some point in the [near or far] future that behavior will remain. Specifically, attempting == (or !=, or synchronization, etc., including compareAndSet) on a reference to a value based class is allowed to do ANYTHING in the future.
For example:
- It may throw an exception (something it should probably start doing ASAP to avoid future surprises).
- It may return always-false, even when the two references are "to the same instance" (and probably will, through many possible value-based compiler optimizations that will erase the unneeded notion of reference and identity).
- It may overwrite random locations in memory or to variables that the code performing the operation has the privilege to write to (which it probably shouldn't, but that's certainly included in what "undefined" and "unpredictable effects" can mean).
- It may sometimes do one of the above, and sometimes seem to be doing what you mean it to do. Switching between modes on a whim (e.g. when a tier 2 optimizing compilation is applied, or when the mutton is nice and lean and the tomato is ripe).

So no, there is no way for compareAndSet to work "correctly" on a reference to an instance of a value-based class. Even if it happens to appear to work "correctly" now, expect it to blow up in bad and potentially silent ways in the future.

— Gil.

> On Jul 5, 2017, at 9:47 PM, Brian S O'Neill <[hidden email]> wrote:
>
> I think the wording in the value-based document is too strong. It's perfectly fine to compare value based instances using ==, but it can lead to confusing results when comparing distinct instances with equivalent state. Using compareAndSet with a box isn't necessary for it to work "correctly" with a value-based class.
>
> By "correctly", I mean the compareAndSet operation works correctly, using == comparison. However, if your intention is for compareAndSet to compare Instants based on their state, then this of course won't work properly.
>
> If you want to perform a compareAndSet for an Instant's state (time since epoch), then you need to use something that can be compared atomically. This means the state must be representable in a 64-bit value or smaller. The Instant class measures time using a 64-bit long and a 32-bit int, and so this state cannot be compared atomically. You'd have to chop off some precision or use something else.
>
>
> On 2017-07-05 09:20 PM, Gil Tene wrote:
>> Reference equality for value based classes (as referenced below) lacks meaning, as there is no notion of identity in such classes (only a notion of value). And since compareAndSet on reference fields is basically an idenitity-based operation [in the compare part], the two won't mix well logically.
>> Specifically, while two references to e.g. java.time.LocalDateTime instances being == to each other *probably* means that the two are actually equal in value, the opposite is not true: Being != to each other does NOT mean that they are logically different. As such, the "compare" part in compareAndSet may falsely fail even when the two instances are logically equal to each other, leaving the rest of your logic potentially exposed.
>> Bottom line: given the explicit warning to not use == and != on references to value-based instances, I'd avoid using compareAndSet on those references. If you really need to use a value-based class in your logic, consider boxing it in another object that has [normal] identity.
>> — Gil.
>>> On Jul 5, 2017, at 8:59 PM, Michael Hixson <[hidden email]> wrote:
>>>
>>> AtomicReference and VarHandle are specified to use == in compareAndSet
>>> (and related) operations [1].  Using == to compare instances of
>>> value-based classes may lead to "unpredictable results" [2].  Does
>>> this mean I should avoid using compareAndSet with arguments that are
>>> instances of value-based classes?
>>>
>>> It seems like the documentation clearly tells me "yes, avoid doing
>>> that" but I'm hoping I misunderstood, or maybe AtomicReference and
>>> VarHandle are exempt somehow.  Otherwise, how do I implement
>>> non-broken compareAndSet and updateAndGet for a java.time.Instant
>>> value for example?  Do I have to box the value in something that's not
>>> a value-based class first, like AtomicReference<Box<Instant>>?
>>>
>>> -Michael
>>>
>>> [1] http://download.java.net/java/jdk9/docs/api/java/util/concurrent/atomic/AtomicReference.html#compareAndSet-V-V-
>>> [2] http://download.java.net/java/jdk9/docs/api/java/lang/doc-files/ValueBased.html
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
 
 

Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany – Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Should I avoid compareAndSet with value-based classes?

Nathan and Ila Reynolds

Perhaps this thread has diverged too far...

Someone wondered on this thread, if synchronized or compare and set would work better under high contention.  The example I have does not use equals() so it does not quite match the original question.  However, the example does use Instant and compareTo() and hence might be similar enough to illustrate.

My program needs an id that is unique even among runs of a singleton process.  I figured the easiest way was to use the current time.  I could have used System.currentTimeMillis() but decided to go with Instant since that would probably make the code easier to understand and maintain.

I had code like the following...

      Instant result;

      result = Instant.now();

      synchronized (Task.class)
      {
         if (result.compareTo(last) <= 0)
            result = last.plusNanos(1);

         last = result;
      }

This code didn't scale.  I changed the code to this...

      Instant result;

      result = Instant.now();

      while (true)
      {
         expect = last.get();    // last is now an AtomicReference

         if (result.compareTo(expect) <= 0)
            result = last.plusNanos(1);

         if (last.compareAndSet(expect, result))
            return(result);
      }
This code scales much better.  I no longer see any scalability or performance issues with this code.  This code is using both identity comparison (i.e. "inside" compareAndSet when comparing expect to the actual current value) as well as compareTo(). 

-Nathan

On 7/9/2017 5:10 PM, Gregg Wonderly wrote:
Anything that is a Number should be performing automatic unboxing to perform literal value comparisons.  I count on this day in and day out.  There is no reason that Number values should ever do anything different.   You can suggest that two Number values which might be typed as Object parameters into a code structure that compares them with ==, will be costly to execute because of runtime type checking.  But, if the developer codes it that way, because they have other Object values which are used in identity comparisons that are logically valid for the code structure, why perform a compile time optimization that invalidates the premise of how identity works against auto-boxing/unboxing?

Gregg

On Jul 6, 2017, at 12:52 PM, Gil Tene <[hidden email]> wrote:

Hence my suggestion that identity-based operations on instances of value-based classes should throw exceptions... Right now they silently do unpredictable things, and should be avoided in any case (but harder to know/find when you accidentally use them).

Sent from my iPad

On Jul 6, 2017, at 10:46 AM, Alex Otenko <[hidden email]> wrote:

Are they subclasses of Object or not? If they are not, no questions. If they are, someone still needs to explain how exactly the “identity based operations” can be avoided safely.

List<j.u.Optional> is just a List underneath, and searching for an item may use “identity based operations”, whether you want it or not - depending on what implementation of List you happen to use.

Alex

On 6 Jul 2017, at 17:33, Gil Tene <[hidden email]> wrote:

It says: "Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects and should be avoided." It does not say what the reason for the unpredictable effect may be and WHEN you shouldn't use identity based operations, it warns you not to use them for any reason whatsoever. Can't be much more clear than that, and you don't need to be a JVM or compiler implementor to understand it. It means "don't do that". And "if you do that, very surprising things may (or may not) happen". 

Acting on a current understanding and perception of what implementations actually do, and saying "I thought that what it really means is that using identity in some way X would be unreliable because of effect Y, but using identity in case Z is ok, because I don't see why it shouldn't be" is a wrong reading of this clear admonition to not use identity for anything. Doing so will come back to bite you, either now or in the future.

For example, instances of value-based classes have the [well documented] quality of being "freely substitutable when equal, meaning that interchanging any two instances x and y that are equal according to equals() in any computation or method invocation should produce no visible change in behavior." The JVM may (and likely will at some point will) use this quality freely in some optimizations, A simple and obviously valid resulting optimization would be for == to always be evaluated as false when the operands are instances of value-based classes: since the JVM *may* freely substitute the instances of either side of the == evaluation with some instance that is equal according to equals(), it can choose to do so in all evaluations of ==, which would mean that the two sides are never the same instance, and would then mean that the JVM can treat all code that would only execute if == were true as dead code. Similarly, != may trivially be evaluated as always-true. And since these optimizations may or may not be applied in different places and times, they may lead to seemingly random evaluation of == or != for identical code on identical data (for the exact same, unmodified values of a and d, a will sometimes be equal to d and sometimes not, and at the same point in code, depending on mood).

We could further discuss whether or not the JVM is allowed to "falsely" indicate that == is true (or that != is false) even when the instances differ in value (so are not .equals()). It is. Doing that may certainly surprise anyone who uses the identity based == for anything to do with instances of value-based classes, even tho using it would be silly given that == might obviously be always-false. For example, I could see how someone may mistakenly try to use == as an "optimization" on the assumption that if they get lucky and == is true, .equals() must be true as well, and that evaluating == might be cheaper, but they would still "do the right thing" in the != case. But that would be a mistake, and a clear violation of the "don't do that" admonition above. The cases where the result of == can be *unpredictable* are not limited to cases where the JVM freely substitutes instances for other equal() ones, that's just one example of how the JVM may obviously and validly use one known quality of value-based classes. But another key quality of instances of value based classes is that they "are considered equal solely based on equals(), not based on reference equality (==)". There is nothing there that limits us to "if == is true, equals() must be true as well". It may be convenient to think otherwise when wanting to explain how breaking the rules in some specific way is still ok (and currently seems to work). But it's not. Bottom line: The JVM *may* choose to make == always-true. Nothing wrong with that.

It is dangerous (and nearly impossible) to deduce which optimizations may or may not happen when they are clearly allowed by the specified set of rules and qualities. The defined qualities are what matter, and optimizations that indirectly result from the propagation of those qualities are allowed and may (or may  not) happen. Instance identity either exists or doesn't, and instance Identity checks either have meaning, or they don't. If they do, certain things follow (like .equals() always being true if the identity of the twin instances is the same, as tested by ==). If they don't, then identity checks are meaningless, and can be discarded or conveniently evaluated in ways that seem profitable.

For "instances" of value-based classes, instance identity does not exist. Unfortunately, unlike value types, where the operand == is defined to act on value and not on identity, the operand == is undefined for instances of value-based classes. It certainly does not mean "if true, the identity of these things is the same", and it certainly doesn't mean "if false, these things are not equal". But it also doesn't mean "if true, these things are equal". It is *undefined*, specified with "may have unpredictable effects", and users are clearly told not to use it for anything.

One can argue that the spec should change, e.g. add a statement that would have the effect of requiring "if == is true then .equals() is also true", and would prevent or limit certain unpredictable effects when considering the identity of identity-less things, but I suspect that writing that down in actual words would be painful given the necessary "there is no meaning to identify, but..." logic. We could also look to redefine the meaning of certain operands, e.g. == and != can be dealt with as they are in value types, but compare in compareAndSet is more challenging...

This is [partly] why I think that throwing an exception (or even a compile-time error where possible) when encountering == or != operations (and any of the other undefined behavior ones) on instances of value-based classes is a good idea, and something that should start happening ASAP. Any such operation is wrong (literally) by definition, and the "may have unpredictable effects" statement in the spec is certainly wide enough to allow exception throwing. It is wide enough to allow much worse things to happen, and silent unpredictable and undefined behavior, while allowed, is worse than preventing the code from executing. The same way we wouldn't argue that synchronized(int) should simply be "undefined" but silently allowed to run with unpredictable effects, we shouldn't argue that synchronized(LocalDateTime) should.

Sent from my iPad

On Jul 6, 2017, at 3:04 AM, Alex Otenko <[hidden email]> wrote:

:-) the one causing Byzantine failures!

Given how underspecified the things generally are, and that the target audience of such javadoc is not a JVM implementor, we shouldn’t read too much into the possible freedoms the vague wording seems to imply. It shouldn’t suddenly break the promises about identity equality for specific instances.

All it’s saying is that, like Integer.from(10) may or may not return the same instance. It may or may not work the same way throughout the JVM’s lifetime, allowing the implementors to choose suitable caching strategies, code optimizations, etc - therefore should not rely on comparing identities, and such; for example, synchronized(Integer.from(10)) does not guarantee neither lock freedom, nor deadlock freedom. It should not say that suddenly it is unsafe to compare identities (like Gil suggests JVM could start throwing exceptions). It should not say that suddenly we shouldn’t be able to CAS (like Gil says suddenly the reference to instance can sneakily be replaced with something else).


Alex


On 6 Jul 2017, at 10:12, Millies, Sebastian <[hidden email]> wrote:

just out of curiosity: I am familiar with the term “Byzantine failure”, but what is a “Byzantine optimization”?
  Sebastian
 
From: Concurrency-interest [[hidden email]] On Behalf Of Alex Otenko
Sent: Thursday, July 06, 2017 10:17 AM
To: Gil Tene
Cc: [hidden email]
Subject: Re: [concurrency-interest] Should I avoid compareAndSet with value-based classes?
 
 
On 6 Jul 2017, at 08:47, Gil Tene <[hidden email]> wrote:
 


Sent from my iPad


On Jul 6, 2017, at 12:38 AM, Alex Otenko <[hidden email]> wrote:

All it is saying is:
 
  LocalDateTime a = LocalDateTime.parse("2007-12-03T10:15:30");
  LocalDateTime b = LocalDateTime.parse("2007-12-03T10:15:30");
  LocalDateTime c = LocalDateTime.parse("2007-12-03T10:15:30");
 
a==b && b==c can be true and can be false
 
It also means that even when:
 
  LocalDateTime d = a;
  ...
  (a == d) may or may not be true. And may change whether it is true or not at any time,
 
I meant an even stronger assertion:
 
assert (a==b) == (b==a) : "No Byzantine optimizations"
assert (a==d) == (a==d): “No Byzantine optimizations"
 
Alex
 


 
 
Alex
 
On 6 Jul 2017, at 08:28, Gil Tene <[hidden email]> wrote:
 


Sent from my iPad


On Jul 5, 2017, at 11:51 PM, Henrik Johansson <[hidden email]> wrote:

Oh, without having followed the value type discussions I think it was a mistake to not "fix" equality. Why not make it a deep comparison if the reference is different? If it points to the same object we are done otherwise start checking the struct content. 
There may be a lot I missed here but a new type of object could be allowed to have different meaning equality. Right?
.equals() means what you want it to mean. == and != (and the compare in compareAndSet) mean very specific things, and cannot be overridden.
 
For non-reference value types (int, long, char, etc.), == and != are value comparisons. An int has no identity. Just a value:
  int a = 5;
  int b = 5;
  boolean y = (a == b);  // true
 
For references to instances of (non value-based) classes, == and != can be thought of as comparing the value of the reference (and not the contents of the object instances). This is an identity comparison, which ignores values within the object:
  Integer a = new Integer(5);
  Integer b = new Integer(5);
  boolean x = a.equals(b);   // true
  boolean y = (a == b);   // false
 
And for references to value-based classes (which is a relatively new thing, but is part of Java 8), the meaning of == and != appears to be undefined. E.g.:
 
  LocalDateTime a = LocalDateTime.parse("2007-12-03T10:15:30");
  LocalDateTime b = LocalDateTime.parse("2007-12-03T10:15:30");
  boolean x = a.equals(b);   // true
  boolean y = (a == b);   // unpredictable, undefined, who knows. 
                                         // Could be true, could be false.
                                         // Could theoretically change the values of a or b, or of something else
 


 
On Thu, 6 Jul 2017, 07:12 Gil Tene, <[hidden email]> wrote:

I'd take that documentation seriously. It basically says that ==, !=, synchronization, identity hashing, and serialization are undefined behaviors.

While the *current* implementations may carry some semi-intuitive behvaiors, e.g. where == indicates true when comparing two references to instances of a value-based class where the value of the references is the same, there is no guarantee that at some point in the [near or far] future that behavior will remain. Specifically, attempting == (or !=, or synchronization, etc., including compareAndSet) on a reference to a value based class is allowed to do ANYTHING in the future.
For example:
- It may throw an exception (something it should probably start doing ASAP to avoid future surprises).
- It may return always-false, even when the two references are "to the same instance" (and probably will, through many possible value-based compiler optimizations that will erase the unneeded notion of reference and identity).
- It may overwrite random locations in memory or to variables that the code performing the operation has the privilege to write to (which it probably shouldn't, but that's certainly included in what "undefined" and "unpredictable effects" can mean).
- It may sometimes do one of the above, and sometimes seem to be doing what you mean it to do. Switching between modes on a whim (e.g. when a tier 2 optimizing compilation is applied, or when the mutton is nice and lean and the tomato is ripe).

So no, there is no way for compareAndSet to work "correctly" on a reference to an instance of a value-based class. Even if it happens to appear to work "correctly" now, expect it to blow up in bad and potentially silent ways in the future.

— Gil.

> On Jul 5, 2017, at 9:47 PM, Brian S O'Neill <[hidden email]> wrote:
>
> I think the wording in the value-based document is too strong. It's perfectly fine to compare value based instances using ==, but it can lead to confusing results when comparing distinct instances with equivalent state. Using compareAndSet with a box isn't necessary for it to work "correctly" with a value-based class.
>
> By "correctly", I mean the compareAndSet operation works correctly, using == comparison. However, if your intention is for compareAndSet to compare Instants based on their state, then this of course won't work properly.
>
> If you want to perform a compareAndSet for an Instant's state (time since epoch), then you need to use something that can be compared atomically. This means the state must be representable in a 64-bit value or smaller. The Instant class measures time using a 64-bit long and a 32-bit int, and so this state cannot be compared atomically. You'd have to chop off some precision or use something else.
>
>
> On 2017-07-05 09:20 PM, Gil Tene wrote:
>> Reference equality for value based classes (as referenced below) lacks meaning, as there is no notion of identity in such classes (only a notion of value). And since compareAndSet on reference fields is basically an idenitity-based operation [in the compare part], the two won't mix well logically.
>> Specifically, while two references to e.g. java.time.LocalDateTime instances being == to each other *probably* means that the two are actually equal in value, the opposite is not true: Being != to each other does NOT mean that they are logically different. As such, the "compare" part in compareAndSet may falsely fail even when the two instances are logically equal to each other, leaving the rest of your logic potentially exposed.
>> Bottom line: given the explicit warning to not use == and != on references to value-based instances, I'd avoid using compareAndSet on those references. If you really need to use a value-based class in your logic, consider boxing it in another object that has [normal] identity.
>> — Gil.
>>> On Jul 5, 2017, at 8:59 PM, Michael Hixson <[hidden email]> wrote:
>>>
>>> AtomicReference and VarHandle are specified to use == in compareAndSet
>>> (and related) operations [1].  Using == to compare instances of
>>> value-based classes may lead to "unpredictable results" [2].  Does
>>> this mean I should avoid using compareAndSet with arguments that are
>>> instances of value-based classes?
>>>
>>> It seems like the documentation clearly tells me "yes, avoid doing
>>> that" but I'm hoping I misunderstood, or maybe AtomicReference and
>>> VarHandle are exempt somehow.  Otherwise, how do I implement
>>> non-broken compareAndSet and updateAndGet for a java.time.Instant
>>> value for example?  Do I have to box the value in something that's not
>>> a value-based class first, like AtomicReference<Box<Instant>>?
>>>
>>> -Michael
>>>
>>> [1] http://download.java.net/java/jdk9/docs/api/java/util/concurrent/atomic/AtomicReference.html#compareAndSet-V-V-
>>> [2] http://download.java.net/java/jdk9/docs/api/java/lang/doc-files/ValueBased.html
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
 
 

Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany – Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-- 
-Nathan

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
123456