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!
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. 🙂
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!
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.
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!
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
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?
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.
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?)
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.
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?
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.
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.
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.
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
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?
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: ua-cam.com/channels/dngmbVKX1Tgre699-XLlUA.html
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.
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.
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.
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?
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.
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!
Thanks - I am happy to hear that! :-)
Your concurrency playlist is the simply the most clear explanation on whole UA-cam. Please continue with more videos on Java Concurrency.
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 :-)
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. 🙂
Great to hear! !! :-)
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!
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.
Very nice explanation and quite interesting to know the internals of JAVA controls used for concurrency and asynchronity
Thanks ! :-)
CAS is the magic that allows you to write non blocking awesomeness )
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!
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
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?
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.
@@JakobJenkov thanks for explaining, Jakob! Your playlist is just brilliant
Finally I grasp how getAndIncrement() works! And how atomic variables make their operations to be atomically. Thank you so much !!!
Great! You are welcome! :-)
Thank you very much! Great explanation 🙂
You are welcome ! 😊
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?)
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.
thank you, I appreciate your video ❤
You are welcome 😊
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?
As far as I know, the threads in Java are OS threads. It is the new Virtual Threads that are user level.
@@JakobJenkov thx for your reply, your videos are really really really good~~
Pure gold!
Thanks! :-)
Very interesting, thank you!
You are welcome! Glad you liked it! :-)
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.
The Unsafe package - is that not being removed or at least restricted in later versions of Java?
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.
Could you please clarify it?
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.
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
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?
Just the time it takes before the OS decides to unblock the thread again that is waiting to enter the synchronized block
how about LongAdder and LongAccumulator ?
thank you!
You are welcome! :-)
Dude u r just amazing 👏
Could u pls help with some kubernetes n cloud related stuff
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: ua-cam.com/channels/dngmbVKX1Tgre699-XLlUA.html
@@JakobJenkov thanks a lot 👍
compareAndSet() vs set() diff?
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.
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.
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.
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?
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.