> On 24 Aug 2016, at 14:17, Martin Buchholz <marti...@google.com> wrote:
> 
> Hi Paul,
> 
> Thanks for doing this.
> 
> Probably your IDE is fixing import statements.  We'd prefer having that not 
> happen for j.u.c. but we can live with it.
> 

Ah, i will update so as not to perturb that.


> Of course, keeping all the variants in sync is errorprone.  Below is one case 
> where what you're testing and what your assertions say are out of sync.  In 
> such cases I've found it better to simply do:
> 
> assertTrue(success);
> assertEquals(x, 1.0d);
> 
> which is more maintainable.  In case of a failure the ever helpful stack 
> trace will let us know what went wrong.
> 

Ooops, i will fix that. We have found it useful to output method to more 
quickly identify what is failing. It’s usually not a lot of work because the 
source is modified in the test templates, but you are correct in saying it is 
not so easy to maintain.

Thanks for the review.

—

It just so happens i am blocked on a x86 byte CAS fix in HotSpot making it’s 
way into jdk9/dev and on the order of patches in my queue (i could rebase,  but 
that is more work). So it may be a week or two before i commit.

Paul.

> @@ -749,9 +749,9 @@
>              for (int c = 0; c < WEAK_ATTEMPTS && !success; c++) {
>                  success = vh.weakCompareAndSetRelease(2.0d, 1.0d);
>              }
> -            assertEquals(success, true, "weakCompareAndSetVolatile double");
> +            assertEquals(success, true, "weakCompareAndSet double");
>              double x = (double) vh.get();
> -            assertEquals(x, 1.0d, "weakCompareAndSetVolatile double");
> +            assertEquals(x, 1.0d, "weakCompareAndSet double");
>          }
> 
>          // Compare set and get
> 
> 
> On Wed, Aug 24, 2016 at 8:45 AM, Paul Sandoz <paul.san...@oracle.com 
> <mailto:paul.san...@oracle.com>> wrote:
> Hi,
> 
> Gentle reminder.
> 
> Paul.
> 
> > On 10 Aug 2016, at 17:03, Paul Sandoz <paul.san...@oracle.com 
> > <mailto:paul.san...@oracle.com>> wrote:
> >
> > Hi
> >
> > Please review:
> >
> >  
> > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename-weakCompareAndSetVolatile/webrev/
> >  
> > <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename-weakCompareAndSetVolatile/webrev/>
> >  
> > <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename-weakCompareAndSetVolatile/webrev/
> >  
> > <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename-weakCompareAndSetVolatile/webrev/>>
> >
> > This is a refactoring to produce a consistent naming scheme for the 
> > VarHandle Read Modify Write (RMW) methods. The unqualified methods default 
> > to volatile access.
> >
> > (And i hope this is the last modifying to the API signatures)
> >
> > This touches 166 classes that use or refer to the weak plain/volatile 
> > methods.
> >
> > The plan is to follow up deprecating (*not* for removal) the 
> > weakCompareAndSet methods on j.u.concurrent.atomic.* classes and add  
> > weakCompareAndSetPlain methods. Analysis via grepcode shows very little 
> > usages of the Atomic*.weakCompareAndSet methods.
> >
> > A further plan is to rename the Unsafe methods s/Swap/Set, add Plain 
> > qualifier etc.
> >
> > Paul.
> 
> 

Reply via email to