Compare and Swap in Java

แชร์
ฝัง
  • เผยแพร่เมื่อ 6 ก.ย. 2024

ความคิดเห็น • 51

  • @brianstuart1126
    @brianstuart1126 3 ปีที่แล้ว +8

    Your concurrency playlist is the simply the most clear explanation on whole TH-cam. Please continue with more videos on Java Concurrency.

    • @JakobJenkov
      @JakobJenkov  3 ปีที่แล้ว +3

      Thank you :-) ... I have covered most of the basics by now. There are still some advanced topics to cover. I will see when I get the time for them :-)

  • @klausdupont6335
    @klausdupont6335 3 ปีที่แล้ว +17

    The illustrations and code examples are not only simple enough for a newcome to understand but also complicated enough to demonstrate use cases. Thanks for the concurrency series!

    • @JakobJenkov
      @JakobJenkov  3 ปีที่แล้ว +2

      Thanks - I am happy to hear that! :-)

  • @volodymyrkomliev5849
    @volodymyrkomliev5849 5 หลายเดือนก่อน +1

    This explanation is brilliant! All these Java Concurrency and Multithreading are amazing! I think every can understand your explanation. Thank you, Jakob, for this useful tutorial. Never be too late to understand Java threads. 🙂

    • @JakobJenkov
      @JakobJenkov  5 หลายเดือนก่อน +1

      Great to hear! !! :-)

  • @susantc5288
    @susantc5288 3 ปีที่แล้ว +3

    I am so grateful that you take the time to do these videos. You had stopped for awhile and now you are back. Thank you so much. You are much appreciated!

    • @JakobJenkov
      @JakobJenkov  3 ปีที่แล้ว +1

      Thank you very much! I am happy my videos are useful for you! :-) I will keep making videos from time to time, but I don't have as much time for it as I had earlier.

  • @krellin
    @krellin 3 ปีที่แล้ว +2

    CAS is the magic that allows you to write non blocking awesomeness )

    • @JakobJenkov
      @JakobJenkov  3 ปีที่แล้ว +1

      Yup :-) ... by the way, I am working on some principles for single-threaded concurrency - meaning making progress on multiple tasks from within a single thread. While non-blocking concurrency is great, no thread problems is even greater :-D ... You can probably not avoid having some level of thread communication - but it can be reduced quite a lot!

    • @krellin
      @krellin 3 ปีที่แล้ว +1

      while i think its a must for any respectable programmer to know how and be able to code using different concurrency approaches... in real production code i do not let people mess with threads, kotlin with coroutines pretty much solved general purpose concurrency for jvm once and for all with the correct way... it is amazing what you can do with a good compiler.. why java compiler devs didn't do it is beyond me, so many issues/bugs could be avoided

  • @kafychannel
    @kafychannel ปีที่แล้ว +2

    Finally I grasp how getAndIncrement() works! And how atomic variables make their operations to be atomically. Thank you so much !!!

    • @JakobJenkov
      @JakobJenkov  ปีที่แล้ว +2

      Great! You are welcome! :-)

  • @kaimingyang4140
    @kaimingyang4140 3 หลายเดือนก่อน +1

    My understanding is: Java threads are all user-level, and there is no need to trap to OS level for context switching. But what you said about Synchronized relies on JVM or OS to keep synchronization. I don’t quite understand the part about (implementation of) Synchronized. Can you recommend some reading materials or make a series of videos to explain JVM in depth?

    • @JakobJenkov
      @JakobJenkov  3 หลายเดือนก่อน

      As far as I know, the threads in Java are OS threads. It is the new Virtual Threads that are user level.

    • @kaimingyang4140
      @kaimingyang4140 3 หลายเดือนก่อน

      @@JakobJenkov thx for your reply, your videos are really really really good~~

  • @akcgupta
    @akcgupta 3 ปีที่แล้ว +1

    Very nice explanation and quite interesting to know the internals of JAVA controls used for concurrency and asynchronity

  • @ggsgetafaf1167
    @ggsgetafaf1167 5 หลายเดือนก่อน +1

    thank you, I appreciate your video ❤

    • @JakobJenkov
      @JakobJenkov  5 หลายเดือนก่อน

      You are welcome 😊

  • @andreytokarskiy9901
    @andreytokarskiy9901 ปีที่แล้ว

    In the first picture, it says that if NO, then keep old value 34. But since it is NO, it is not 34 any more. So, it should just say, keep old value of var whatever it is. Thank you

  • @AlexeySilichenko
    @AlexeySilichenko ปีที่แล้ว +1

    Thank you very much! Great explanation 🙂

    • @JakobJenkov
      @JakobJenkov  ปีที่แล้ว +1

      You are welcome ! 😊

  • @ultrablack7271
    @ultrablack7271 3 ปีที่แล้ว +2

    Very interesting, thank you!

    • @JakobJenkov
      @JakobJenkov  3 ปีที่แล้ว

      You are welcome! Glad you liked it! :-)

  • @LucAlucard1
    @LucAlucard1 7 หลายเดือนก่อน +1

    Professor, thanks for this explanation!
    One question, should we always use `.compareAndSet` method from any Athomic data structure to deal with multi-threads? I'm asking that because I've seem multiple codes using `AtomicLong`, `AtomicInt`, `AtomicWhatever`, only like `atomicLong = atomicLong + 1`. If I understood correctly, use it like that may lead to the same issues as an usual `Long`. Is my understanding correct?

    • @JakobJenkov
      @JakobJenkov  7 หลายเดือนก่อน +2

      You should always update the state of the _same_ AtomixXYZ instance using its methods. It can be set(), compareAndSet() or whatever else method you need in the given situation.

    • @LucAlucard1
      @LucAlucard1 7 หลายเดือนก่อน

      @@JakobJenkov thanks for explaining, Jakob! Your playlist is just brilliant

  • @andrewshatnyy
    @andrewshatnyy 3 ปีที่แล้ว +1

    Pure gold!

  • @ggir9979
    @ggir9979 2 ปีที่แล้ว +1

    The AtomicBoolean class uses the new (since Java 9) varHandle class for performing the compareAndSet natively.
    Could you make a video on varHandle and the Unsafe package? It's got so much goodies in it for advanced java programming, but it's been hard to find a good tutorial.

    • @JakobJenkov
      @JakobJenkov  2 ปีที่แล้ว

      The Unsafe package - is that not being removed or at least restricted in later versions of Java?

  • @smitmandavia5044
    @smitmandavia5044 7 หลายเดือนก่อน

    Thanks for the video!
    Now that we have virtual threads, do you think they would be using something similar to compare and set lock?
    Or even locks in virtual threads are expensive than compare and set lock? (If not, why not do so?)

    • @JakobJenkov
      @JakobJenkov  7 หลายเดือนก่อน

      Virtual threads are not lighter than platform threads when it comes to locking. It's the same underlying mechanism as far as I understand. The only difference is, that virtual thread that is blocked can be "detached" from the platform thread executing it, and the platform thread can then execute another virtual thread.

  • @TrieuPham749
    @TrieuPham749 3 ปีที่แล้ว +1

    Hi as you said that atomic operator compareAndSwap only run for 1 thread because CPU and chipset. Why don't we define an atomic operator called : increase(int delta). In this operator we get the volatile original value then originalValue+=delta. So we don't need to compare and resolve ABA problem.

    • @TrieuPham749
      @TrieuPham749 3 ปีที่แล้ว

      Could you please clarify it?

    • @JakobJenkov
      @JakobJenkov  3 ปีที่แล้ว +1

      The AtomicLong class has methods for incrementing and adding atomically, as far as I remember. But this video is about the compare and swap technique in general, so I focused on yhe features related to that.

  • @9714
    @9714 ปีที่แล้ว

    how about LongAdder and LongAccumulator ?

  • @akashagarwal6390
    @akashagarwal6390 ปีที่แล้ว

    compareAndSet() vs set() diff?

    • @JakobJenkov
      @JakobJenkov  ปีที่แล้ว

      compareAndSet() only sets the value if the value compared to is equal to the value before the "set" of the new value. Otherwise it will not set a new value.

  • @sumitkumarmahto5081
    @sumitkumarmahto5081 3 ปีที่แล้ว

    Hi Jakob,
    I had a doubt here, in the 1st scenario what causes that delay(wasted time by thread 1) even after the thread 2 has left the synchronized block?

    • @JakobJenkov
      @JakobJenkov  3 ปีที่แล้ว +2

      Just the time it takes before the OS decides to unblock the thread again that is waiting to enter the synchronized block

  • @TheGuroguro12
    @TheGuroguro12 ปีที่แล้ว

    thank you!

  • @croydon21H
    @croydon21H 3 ปีที่แล้ว

    I am unable to relate this to real world scenario , lets say a bank. what is the use case? add 1 is a literal and understand it can be 34 or 83, but it still is a literal.

    • @JakobJenkov
      @JakobJenkov  3 ปีที่แล้ว

      Compare and swap is usually used when you need high performance (low latency) thread communication. In a bank that would happen inside the bank's database. You might not see it in your own code. In Java code it might be used e.g. in a custom queue implementation such as the LMAX disrupter or some of the concurrent queues in the JC Tools open source project. I am not saying that these tools use compare and swap - but they could.

  • @chitthiaayeehai
    @chitthiaayeehai 3 ปีที่แล้ว +1

    Dude u r just amazing 👏
    Could u pls help with some kubernetes n cloud related stuff

    • @JakobJenkov
      @JakobJenkov  3 ปีที่แล้ว +1

      Hi Debashis, thanks! I don't know enough about Kubernetes to make videos about it, unfortunately. But TechWorld With Nana (YT channel) has some videos about both Kubernets and Docker: th-cam.com/channels/dngmbVKX1Tgre699-XLlUA.html

    • @chitthiaayeehai
      @chitthiaayeehai 3 ปีที่แล้ว

      @@JakobJenkov thanks a lot 👍

  • @aleksandrkravtsov8727
    @aleksandrkravtsov8727 ปีที่แล้ว +1

    Is it correct that CAS and Monitor can be replaced with each other in every use case or there are use cases when Monitor can't do what CAS can and vice versa?

    • @JakobJenkov
      @JakobJenkov  ปีที่แล้ว +1

      A monitor object in Java requires a synchronized block a is as such a blocking operation. As far as I understand, a CAS is atomic but not blocking. You could use CAS to implement a monitor / mutex in Java, and probably also use a monitor / synchronized block to implement CAS. Also, since CAS is not blocking, you could use CAS to implement an optimistic locking style of guarding code around a critical section - to avoid blocking a thread.