-1

I have a very dumb question. If I use AtomicReferences compareAndSet this way 

    original.set(atomic.get());
    long next = some new value
    atomic.compareAndSet(original.get(), next);
    ....more code....

is more code still updated if the comparison fails (i.e. atomic has been updated by another thread). I'm trying to find an error in an assignment and this is the only thing I can think about and I've been trying for few hours.

P.S. Weirdly enough, if I use synchronize on this code it gives me the correct answer on my laptop, but not on my desktop

Olli
  • 906
  • 10
  • 25
  • It’s a method like any other. Execution continues to the next statement. Add an if statement if you want more code to execute conditionally. – Sotirios Delimanolis Apr 14 '20 at 14:06
  • You need to check if compareAndSet is successful with a conditional statement. See the last section - http://tutorials.jenkov.com/java-util-concurrent/atomicboolean.html – Mangat Rai Modi Apr 14 '20 at 14:15
  • @MangatRaiModi Thank you, this fixed my code. Any idea on why this would work with synchronized on my laptop but not on PC? – Olli Apr 14 '20 at 14:17
  • @SotiriosDelimanolis Thank you, an if statement fixed it all. I had somehow had the idea that this works like a while loop, that it loops until it succeeds. But I was clearly wrong. Thanks a lot! – Olli Apr 14 '20 at 14:17
  • 1
    Yeah, it is typically used with loops. But alone doesn’t guarantee much. – Sotirios Delimanolis Apr 14 '20 at 14:20
  • @SotiriosDelimanolis thank you. I somehow can't upvote, but I really appreciate your help. – Olli Apr 14 '20 at 14:21
  • @Olli concurrent access if wrongly implement might work or break sometimes. The behavior is undefined. You have a bug. Often due to latency differences, you can see things working in 1 environment and not other. – Mangat Rai Modi Apr 14 '20 at 14:47
  • 1
    @MangatRaiModi Thank you. Yes, I found the bug thanks to you two. I had incorrectly assumed that this would keep trying until true. The Book link you provided is actually my textbook, nice. This website is also great, it's actually helped me with last week's assignment about Reentrant Locks. I also liked the packt book. – Olli Apr 14 '20 at 15:17
  • You are on right track. – Mangat Rai Modi Apr 14 '20 at 15:42

1 Answers1

0

MangatRaiModi and SotiriosDelimanolis put me on the right path. A simple fix:

    original.set(atomic.get());
    long next = some new value
    while(!atomic.compareAndSet(original.get(), next))
    {
      do above again
    }
    ....more code....

did it. Still not sure how synchronized fixed this on my laptop but not on my desktop. I'm guessing that it's slowing the threads down on the mobile Chip enough so that they can operate sequentially (Like a Print statement). I'm probably wrong though.

Olli
  • 906
  • 10
  • 25
  • synchronised and compareAndSet are very different in symantics. Synchronised block take a lock, so that no other thread can execute that piece of code. So it works. CompareAndSet actually checks if the value has been changed from the original, if yes it doesn't set. It is an atomic operation. Concurrency is tricky and very easy could lead to bugs. I would strongly reccomend to do some online course or read about it. Try these 2 https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601 http://tutorials.jenkov.com/java-concurrency/index.html – Mangat Rai Modi Apr 14 '20 at 14:46
  • @MangatRaiModi Thank you, I'm doing this actually as part of an assignment for my Uni Course in Concurrency and Parallel Programming, it's about implementing a Linear Congruential Generator for Random numbers. One of Course Textbooks is actually the first link you provided. I was able to do it using a lock and synchronized and now the third part is using atomic variables. – Olli Apr 14 '20 at 14:57