Many praised the presenter for his clear explanation of different Java Concurrency concepts with this playlist. I have to agree. However, I felt that the better he was, the more significant damage he had done. I am pretty sure no one here cares about the difference between data race and race condition anymore as he had combined the two into one. Data race (accessing and modifying same memory location from different threads) and race condition (timing and ordering of each statement affect the correctness of your program) are two different concepts mentioned in the classic Java Concurrency In Practice by Brian Goetz. Here is a quote from an article by John Regehr, Professor of Computer Science, University of Utah, USA: "In practice there is considerable overlap: many race conditions are due to data races, and many data races lead to race conditions. On the other hand, we can have race conditions without data races and data races without race conditions."
I have yet to see a good example of a case that has "data races without race conditions" or "race conditions without data races". Therefore I left it out. The day I find clear definitions and distinctions - I might make a new video about the difference between the two. Academics are notoriously bad at communicating their ideas - in my opinion - after having read lots of academic literature over the years. Their language is cluttered and unclear, and often assume a large amount of preexisting knowledge in their readers. Sometimes their ideas are even out of touch with reality. That is one of the main reasons I am making these videos and textual tutorials - to try to make the topics easier to understand. But I can only make the material as correct as the material I am able to find and understand on the topics I cover. And I cannot spend my entire life looking for that one, great article behind some scientific journal's paywall. If you have any links - I'd be happy ! ... by the way - even Java Concurrency in Practice is unclear about several topics. For instance - what does "thread visibility" mean? The book kind of throws that term out there - without giving a clear definition. That is the space we are operating in - a space with unclear information and incomplete knowledge. I am trying to navigate that as well as I can - and trying to help others navigate it too.
@@JakobJenkov Thank you for replying to my comment. I agree with you that Java Concurrency in Practice is unclear on many topics, and your website was my primary source for understanding that book ten years ago. For that, I would like to thank you again. I didn’t mean for my comment to take away your contribution to the Java newcomers understanding the topic of concurrency. On the contrary, I believe your texts and videos are so popular that I saw many StackOverflow posts referring to your writing, and I would like to see if my comment would help make it better. Going back to the examples of the two cases, the reason I mentioned John Regehr and his article was hoping someone may google “John Regehr Race condition Data Race”. The first result should be one of his blogs, “Race Condition Vs. Data Race”. It is hard to say whether the bank account examples are good as they are trivial. But the conclusion is clear, that “data race without race condition” is usually harmless in a language with a good memory model, which I believe is true after Java fixed its memory model with the “happens-before” guarantee (JSR-133). However, I wouldn’t say the same about "race conditions without data races", which is basically the reason why you put “sychronized” in every method of your class doesn’t make it thread-safe. Feel free to correct my comments above, as I would like to continue learning more about Java concurrency.
@@destandphron4036 "which is basically the reason why you put “sychronized” in every method of your class doesn’t make it thread-safe" how does using synchronized almost everywhere not make it thread-safe?
God of Concurency..i have bene flowing you since my 2014 when you used to write blog post only...by going through your post i attend interview like a LION when they ask mutithreading qns.........Thanks a Lot form 10+ yrs exp guy from BLR,India.
Thanks so much for this series. I have been using your resources for a while now. And I appreciate the time you took to put it together. You know how it goes. you do this for a while and once in a while you need a really good refresher. This is an awesome refresher. Thanks much.
Thank you ! I would have wished that too ! That is why I started making tutorials. Tech could be easier to learn, if materials were written differently !
Hi Kasim, I have several more videos planned within Java Concurrency, and I will try to get around to the more advanced concepts too - although I prefer a concurrency model where threads do not share data - and where you thus don't need as many concurrency constructs (locks, semaphores etc). for the model to work.
Was there a particular benefit of using a ConcurrentHashMap in this example rather than a regular HashMap since both read and write access had to be synchronized anyways?
In case access to the Map is guarded by a synchronized block - there is not really any advantage of using a ConcurrentHashMap. In practice, you would try only to use the ConcurentHashMap.
In case when we make the critical section synchronized that is check if the value is null , are we sort of making concurrent hashmap to work like a synchronized hashmap , because only one thread can run at a time and sort of blocking happens. Maybe if we put something while(sharedMap.containsKey("key") ) . so that condition is checked again in case of threads
The exames shown in this video are not examples of perfect code. They are created specifically to illustrate certain points. All the examples could be improved depending on the circumstance in which they are to be used.
just a small note: 16:45 - you mentioned "the concurrentHashMap" is capable of having multiple threads access it at the same time without the HashMap becoming internally inconsistent". When you say "without the HashMap becoming internally inconsistent" what precisely do you mean? Because what you have immediately afterwards exemplified seems contradictory to statement to me. "capable of..." != "always guaranteeing..."? You basically showed that IT CAN happen that a ConcurrentHashMap object might be in an inconsistent state, right? I mean: both threads passed the if-check, but then immediately after only one of them removes the key, the other gets a NULL. This is an inconsistent state, right? Thank you! Also: how would we do it in such a way so that we wouldn't need to use "synchronized" ourselves for this specific example?
A ConcurrentHashMap will always be internally consistent - meaning it is thread safe. However, you can still use a ConcurrentHashMap in a way that makes its state be out of sync with the world around it. But it will never have dangling pointers internally, or anything like that.
Hi Jakob, first I want to thank you for these amazing videos about concurrency. And I want to ask you something. You started the video with this example with counter variable, and you're talking about the critical section, and you said that "This section of code here this.count++ where the problem happens, when the race condition happens is called a critical section. First we read the value of the count variable into a local CPU register, then the new value is set as the old value plus 1, so the new value depends on the old value, and then we write it back to count." But in this case the count variable isn't volatile. So it is possible to read the value from main memory to CPU register and then write it back to main memory if the count variable isn't volatile?
Yes, that is correct. Volatile variables are written directly to main memory, whereas non-volatile variables may be located in a CPU register until the Java VM decides to flush it to main memory so it becomes visible to other threads.
09:40 - 09:45 "whatever thread is last always finishes with a count of 2 million" - if that is so, then why is it that Thread2 is FIRST displayed, yet it finisehd with 2 million? How does flushing to console (output) work? I was expecting the last to finish is the last to run System.out.println(), yet it seems that is not the case judging by the output in the console. Am I expecting wrong?
Yes, you are expecting wrong. You don't have any guarantees about the order in which calls to System.out.println() by different threads are flushed to the console. You might see two threads writing almost at the same time - have their lines switched.
No, that would not be enough in this case. Volatile is only enough to guarantee visibility between threads - but by itself it is rarely enough to guard against race conditions. There are some non-blocking concurrent algorithms that use volatile variables in their implementation though - which can guard against race conditions, but these algorithms are not trivial to implement or design!
You cannot control which thread comes first always, since you do not control the thread scheduler. What you can control is that only one thread at a time executes the critical section.
Thank you Jakob for great video and texts about concurrency. In ua-cam.com/video/RMR75VzYoos/v-deo.html you have also 'return this. count;' in sync block. I think it's not necessary. And better is to put only necessary code of count++; to that block. Am I right?
Many praised the presenter for his clear explanation of different Java Concurrency concepts with this playlist. I have to agree. However, I felt that the better he was, the more significant damage he had done. I am pretty sure no one here cares about the difference between data race and race condition anymore as he had combined the two into one. Data race (accessing and modifying same memory location from different threads) and race condition (timing and ordering of each statement affect the correctness of your program) are two different concepts mentioned in the classic Java Concurrency In Practice by Brian Goetz.
Here is a quote from an article by John Regehr, Professor of Computer Science, University of Utah, USA: "In practice there is considerable overlap: many race conditions are due to data races, and many data races lead to race conditions. On the other hand, we can have race conditions without data races and data races without race conditions."
I have yet to see a good example of a case that has "data races without race conditions" or "race conditions without data races". Therefore I left it out. The day I find clear definitions and distinctions - I might make a new video about the difference between the two. Academics are notoriously bad at communicating their ideas - in my opinion - after having read lots of academic literature over the years. Their language is cluttered and unclear, and often assume a large amount of preexisting knowledge in their readers. Sometimes their ideas are even out of touch with reality. That is one of the main reasons I am making these videos and textual tutorials - to try to make the topics easier to understand. But I can only make the material as correct as the material I am able to find and understand on the topics I cover. And I cannot spend my entire life looking for that one, great article behind some scientific journal's paywall. If you have any links - I'd be happy ! ... by the way - even Java Concurrency in Practice is unclear about several topics. For instance - what does "thread visibility" mean? The book kind of throws that term out there - without giving a clear definition. That is the space we are operating in - a space with unclear information and incomplete knowledge. I am trying to navigate that as well as I can - and trying to help others navigate it too.
@@JakobJenkov Thank you for replying to my comment. I agree with you that Java Concurrency in Practice is unclear on many topics, and your website was my primary source for understanding that book ten years ago. For that, I would like to thank you again. I didn’t mean for my comment to take away your contribution to the Java newcomers understanding the topic of concurrency. On the contrary, I believe your texts and videos are so popular that I saw many StackOverflow posts referring to your writing, and I would like to see if my comment would help make it better.
Going back to the examples of the two cases, the reason I mentioned John Regehr and his article was hoping someone may google “John Regehr Race condition Data Race”. The first result should be one of his blogs, “Race Condition Vs. Data Race”. It is hard to say whether the bank account examples are good as they are trivial. But the conclusion is clear, that “data race without race condition” is usually harmless in a language with a good memory model, which I believe is true after Java fixed its memory model with the “happens-before” guarantee (JSR-133). However, I wouldn’t say the same about "race conditions without data races", which is basically the reason why you put “sychronized” in every method of your class doesn’t make it thread-safe. Feel free to correct my comments above, as I would like to continue learning more about Java concurrency.
@@destandphron4036 "which is basically the reason why you put “sychronized” in every method of your class doesn’t make it thread-safe"
how does using synchronized almost everywhere not make it thread-safe?
God of Concurency..i have bene flowing you since my 2014 when you used to write blog post only...by going through your post i attend interview like a LION when they ask mutithreading qns.........Thanks a Lot form 10+ yrs exp guy from BLR,India.
Thanks :-)
Thanks :-)
Amazing video, the easiest explanation I have ever seen. You are doing a great job.
Thank you very much :-)
I owe so much to Jakob. If I know java it is because of his articles. Glad that he is running his own channel now
I am happy my tutorials and videos have helped you out! :-)
Thanks so much for this series. I have been using your resources for a while now. And I appreciate the time you took to put it together. You know how it goes. you do this for a while and once in a while you need a really good refresher. This is an awesome refresher. Thanks much.
Thank you for your kind words - and you are welcome! :-)
I wish they could have taught the same way in my college. Great work, man!!
Thank you ! I would have wished that too ! That is why I started making tutorials. Tech could be easier to learn, if materials were written differently !
Thank you so much for the huge amount of effort that you put into your videos and text tutorials, also congratulations on becoming a Java Champion 🏆
Thank you very much! :-)
Once I'll have some money, I'll donate some of it to you. Thank you for creating this playlist!
You are welcome!! :-) In the meantime - you can always share it with whoever you think could benefit from it - that would be very helpful too ! :-)
this is an awesome explanation. It goes into great detail and is easy to understand
I am glad you think so :-)
Nice example with a concurrent map!
Thank you :-)
Please make more videos on advanced concurrency topics like Latches, Phaser etc.
Hi Kasim, I have several more videos planned within Java Concurrency, and I will try to get around to the more advanced concepts too - although I prefer a concurrency model where threads do not share data - and where you thus don't need as many concurrency constructs (locks, semaphores etc). for the model to work.
Was there a particular benefit of using a ConcurrentHashMap in this example rather than a regular HashMap since both read and write access had to be synchronized anyways?
In case access to the Map is guarded by a synchronized block - there is not really any advantage of using a ConcurrentHashMap. In practice, you would try only to use the ConcurentHashMap.
i can´t thank enough for this video. soooo simple and straight in the point
Thank you very much! I am glad it was helpful! :-)
A very clear instruction, thank you 😊
You are welcome! :-)
In case when we make the critical section synchronized that is check if the value is null , are we sort of making concurrent hashmap to work like a synchronized hashmap , because only one thread can run at a time and sort of blocking happens. Maybe if we put something while(sharedMap.containsKey("key") ) . so that condition is checked again in case of threads
The exames shown in this video are not examples of perfect code. They are created specifically to illustrate certain points. All the examples could be improved depending on the circumstance in which they are to be used.
@@JakobJenkov Thanks for your reply , got your point .Bdw I am really enjoying and learning a lot from your playlist . Hope to see more in future.
really helpful and illuminating
Happy to hear that! :-)
just a small note:
16:45 - you mentioned "the concurrentHashMap" is capable of having multiple threads access it at the same time without the HashMap becoming internally inconsistent".
When you say "without the HashMap becoming internally inconsistent" what precisely do you mean?
Because what you have immediately afterwards exemplified seems contradictory to statement to me. "capable of..." != "always guaranteeing..."? You basically showed that IT CAN happen that a ConcurrentHashMap object might be in an inconsistent state, right? I mean: both threads passed the if-check, but then immediately after only one of them removes the key, the other gets a NULL. This is an inconsistent state, right?
Thank you!
Also: how would we do it in such a way so that we wouldn't need to use "synchronized" ourselves for this specific example?
A ConcurrentHashMap will always be internally consistent - meaning it is thread safe. However, you can still use a ConcurrentHashMap in a way that makes its state be out of sync with the world around it. But it will never have dangling pointers internally, or anything like that.
Hi Jakob, first I want to thank you for these amazing videos about concurrency. And I want to ask you something. You started the video with this example with counter variable, and you're talking about the critical section, and you said that "This section of code here this.count++ where the problem happens, when the race condition happens is called a critical section. First we read the value of the count variable into a local CPU register, then the new value is set as the old value plus 1, so the new value depends on the old value, and then we write it back to count." But in this case the count variable isn't volatile. So it is possible to read the value from main memory to CPU register and then write it back to main memory if the count variable isn't volatile?
Yes, that is correct. Volatile variables are written directly to main memory, whereas non-volatile variables may be located in a CPU register until the Java VM decides to flush it to main memory so it becomes visible to other threads.
Very good explanation thanks for it just amazing to listen it.
You are welcome! Glad it was helpful! :-)
Very good explanation, thank you.
You are welcome :-)
09:40 - 09:45 "whatever thread is last always finishes with a count of 2 million" - if that is so, then why is it that Thread2 is FIRST displayed, yet it finisehd with 2 million?
How does flushing to console (output) work?
I was expecting the last to finish is the last to run System.out.println(), yet it seems that is not the case judging by the output in the console. Am I expecting wrong?
Yes, you are expecting wrong. You don't have any guarantees about the order in which calls to System.out.println() by different threads are flushed to the console. You might see two threads writing almost at the same time - have their lines switched.
does making the count field as volatile will work ??
No, that would not be enough in this case. Volatile is only enough to guarantee visibility between threads - but by itself it is rarely enough to guard against race conditions. There are some non-blocking concurrent algorithms that use volatile variables in their implementation though - which can guard against race conditions, but these algorithms are not trivial to implement or design!
@@JakobJenkov great..!! thanks for the explanation..
How frequently threads write local variables to main-memory?
That is not known. But you can force a thread to synchronize with main memory using synchronized blocks or volatile variables.
What code we need to put, if we want to know who’s the winner? Or should i say who comes first?
You cannot control which thread comes first always, since you do not control the thread scheduler. What you can control is that only one thread at a time executes the critical section.
Okay, so i need a different code for my case?
Btw, thank you!
Can you please upload the programs as well?
In my next video (which I am working on right now) I will upload the code to a GitHub repo, so people can browse it at their own speed.
GOOOOOOOOOOD!!!!!
Thanks :-)
Good explanation but slow, thanks
Thank you Jakob for great video and texts about concurrency.
In ua-cam.com/video/RMR75VzYoos/v-deo.html you have also 'return this. count;' in sync block. I think it's not necessary. And better is to put only necessary code of count++; to that block. Am I right?
Yes, you could probably move the return this.count outside the synchronized block.