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.
So if a thread locks a ReentrantLock lock, a lock is locked and will not be unlocked until the lock count of the lock is 0. And before that lock unlocks it blocks the other threads until they get their own chance to lock a lock and increase its lock counter, then they get the lock unlocked and the next thread is ready to lock the lock. Wow, it locks really good.
@@JakobJenkov probably it's possible to use another verb instead of "lock" to reduce this effect, maybe like: "lock and unlock the lock" -> "close and open the lock" or "occupy and unoccupy the lock" or "turn on and turn off the lock" or "capture and free the lock" I'm not really sure though, cause locking and unlocking sound the most natural for locks :)
Thank you very much! Glad my videos help you! I will continue, although I have less time than I did previously to make videos. But I will release some from time to time - like I just did today (about Thread Congestion in Java).
Thanks again for the great detailed videos! :D The best video I could find for multithreading and concurrency. One suggestion is to also explain example use case of lockInterruptible.
Hello Jakob, I just found your channel today while searching for Java multi-threading tutorials. Your videos are the best ones that I have come across. I just realized that this video was posted today while I was watching your playlist on multi-threading. Timely post I guess :D. Are you going to post more videos on this topic?
How lucky 😁 Yes, I plan to still add more videos within this topic. There are several basic topics to cover, and I also want to cover various thread architectures.
Confirmed. I like the quality and detailsation of your videos and articles. Only your competitors are (I would say if you let me) Baeldung and Mkyong. 😊 PS: just realized that Baeldung is not a person 🤣...
Hi Jakob, great content as usual but i am adding a small suggestion that you should've explained about other implementations of Lock interface and how many locks are there in java etc.
Hi Jakob, thank you for your good explanation and your efforts. Just to confirm that the two Counter implementations CounterSynchronized and CounterLock are not equivalents? In the first one, the methods inc() and getCount() can be called "simultaneously" by two threads. In the second one, the same Lock Object is used in the two methods, so they can't be called "simultaneously" by two different threads.
No - in CounterSynchronized only 1 thread can call either inc() or getCount() at a time, because both methods are synchronized (on the object instance). That is also the case with CounterLock.
Hi Jakob. Your blog and videos are always helpful to me, in getting my job and performing well in it. Have you got a patreon or is there a way I can buy you a coffee? Keep up the great work
Thank you! Glad my tutorials are helpful! I did have a Patreon account once, but nobody every signed up (developers like free stuff ;-) ), so I shut it down again.
It does not _have to_ - but in case your code does it - if the lock is reentrant, it will not cause any problems retaking the lock by the thread that already holds it.
Hi Jakob, the tutorials are great, in fact I can say its the best I have found so far on multithreading. One question I have is for the tryLock() example. When thread3 is in queue and waiting for 1000ms, does it need to be next in line to be able to lock the Lock or can it be in any part of the queue and will still be able to lock the Lock if the Lock is unlocked during that 1000ms time?? From what you said in the video, I think the thread has to be next in line to be able to lock the Lock but just want to confirm if I understand it correctly.
When in doubt about a detail like this, it can be a good idea to check the official JavaDoc for the given method. There you can often find such details listed. The tryLock() method without a timeout does *not* respect other threads waiting in line to lock the ReentrantLock. The tryLock(timeout) method - the version with a timeout - *does* respect other threads waiting in line to lock the Lock. See the official JavaDoc here: docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html#tryLock(long,java.util.concurrent.TimeUnit)
Are there any difference if you put lock.lock() right before try-finally block and not within try block? For example The art of multiprocessor programming suggest the approach with acquiring lock before entering try block.
Hi Jokob at minute 10:24 lock is called one time in the calculate method. How is it possible to execute add/subtract if the lock was already called without unlock ?
Since reading a variable doesn't change it - synchronization / locking is not necessary to guarantee correct behaviour. However, to guarantee "visibility" of the variable that is protected by the Lock - you should consider locking and unlocking when accessing it (or make the variable itself volatile).
I believe usually we do not apply locks to reading the variables. As per Jacob, I learnt that making writes to variables definately will require locks to perform this kind of operation and also to make it visible what changes you are making, you need to make that variable volatile. Otherwise, there is no guarantee that your changes are shown to other threads also. Hence, usually for a method like setter makes sense to have keyword like synchronized. Correct me if I am wrong, Jacob :) .
Hi Kaixun, thank you for notifying me! ... the server hosting tutorials.jenkov.com is getting old, and has become a bit unstable unfortunately. This is the 3rd crash within a short time period. I will be moving all the tutorials to jenkov.com soon though (a few are already moved) .
In this case - no, there is not. The access pattern (check-then-update) means that simply using a volatile variable is not enough - you need the atomicity of a synchronized block, or a critical section guarded by a Lock. However, once you have a synchronized block or a block guarded by a Lock, you no longer need the variable to be volatile - because the synchronized block / Lock guarded block provides the same visibility guarantees as a volatile variable does.
I understand what you said but still I am in confusion can you explain even better. You teaching is excellent but I am not able to understand (my fault )...!!!!!
this whole java concurrency series is priceless. Thank you for the great pacing, examples and time spent to record it!
Thank you! I am happy you find it useful! :-)
Jakob my beloved, I cannot ever thank you enough. The Java community is a better place with teachers like you in it, thank you!!
Thank you very much for your kind words !! :-)
I'm insanely grateful for this series, you explain everything in the best way possible!
Thank you !! :-) ... and you are welcome :-)
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 a lot ! :-)
Drinking game: Every time Jakob says "lock", take a shot
😊
got alcohol poisoning ty
So if a thread locks a ReentrantLock lock, a lock is locked and will not be unlocked until the lock count of the lock is 0. And before that lock unlocks it blocks the other threads until they get their own chance to lock a lock and increase its lock counter, then they get the lock unlocked and the next thread is ready to lock the lock.
Wow, it locks really good.
This is the best tutorial ever. Thank you for doing this!
Thanks! ... and you are welcome ! :-)
This the level of explanation that looked for!
Great videos!
Great !! 😊😊
Probably the best tutorial about the Lock interface. also, I can feel semantic satiation happening for you because of the word "lock". 😁
Thanks ! ... yes, it was hard to say the word "Lock" all these times! :-D ... I remember making many mistakes during recording :-D
@@JakobJenkov probably it's possible to use another verb instead of "lock" to reduce this effect, maybe like:
"lock and unlock the lock" -> "close and open the lock" or "occupy and unoccupy the lock" or "turn on and turn off the lock" or "capture and free the lock"
I'm not really sure though, cause locking and unlocking sound the most natural for locks :)
Hi, Jakob. Your videos are really useful to me and thanks a lot. Please continue!
Thank you very much! Glad my videos help you! I will continue, although I have less time than I did previously to make videos. But I will release some from time to time - like I just did today (about Thread Congestion in Java).
keep up the great work, you deserve to have millions of subs and views 💯
Thanks :-D ... I wish ! ;-)
Thanks again for the great detailed videos! :D The best video I could find for multithreading and concurrency.
One suggestion is to also explain example use case of lockInterruptible.
13:25 now I know what "starvation" means in multithreading context.
Hello Jakob, I just found your channel today while searching for Java multi-threading tutorials. Your videos are the best ones that I have come across.
I just realized that this video was posted today while I was watching your playlist on multi-threading. Timely post I guess :D.
Are you going to post more videos on this topic?
How lucky 😁 Yes, I plan to still add more videos within this topic. There are several basic topics to cover, and I also want to cover various thread architectures.
Confirmed. I like the quality and detailsation of your videos and articles.
Only your competitors are (I would say if you let me) Baeldung and Mkyong. 😊
PS: just realized that Baeldung is not a person 🤣...
Baeldung started out as a single person, but then he started hiring writers.
@@JakobJenkov That's awesome. Looking forward to learn more from you! 😊
I can only second that!
I watched various videos but this one was the best. Thanx for such great video. And keep spreading knowledge😁....
You are welcome - and thank you for your kind words! :-)
22:23 good explanation on use case for try lock.
Thank you Jakob for this awesome video that enlightened the topic for me!
You are welcome! :-)
Hi Jakob, Thnx for such a great tutorial. I wonder How do you create the diagrams which you use during the lectures?
I use various diagram software :-)
Hi Jakob, great content as usual but i am adding a small suggestion that you should've explained about other implementations of Lock interface and how many locks are there in java etc.
You can look that information up in the JavaDoc :-)
Hi Jakob, thank you for your good explanation and your efforts. Just to confirm that the two Counter implementations CounterSynchronized and CounterLock are not equivalents? In the first one, the methods inc() and getCount() can be called "simultaneously" by two threads. In the second one, the same Lock Object is used in the two methods, so they can't be called "simultaneously" by two different threads.
No - in CounterSynchronized only 1 thread can call either inc() or getCount() at a time, because both methods are synchronized (on the object instance). That is also the case with CounterLock.
Brother your content is really top notch, keep doing the good work. Thanks 👍🏻
Thank you ! I really appreciate your feedback! :-)
Your tutorials are amazing!!
Thanks :-)
Hi Jakob. Your blog and videos are always helpful to me, in getting my job and performing well in it. Have you got a patreon or is there a way I can buy you a coffee? Keep up the great work
Thank you! Glad my tutorials are helpful! I did have a Patreon account once, but nobody every signed up (developers like free stuff ;-) ), so I shut it down again.
Crystal clear explanation!
Thank you ! Great to hear! :-)
"lock the lock" for the amazing explanation :D
Yeah... then that topic is locked in 😉
Hi Jakob, One Question when a thread acquires a lock then why it needs to acquire the lock again which is basically the ReEntrant lock?
It does not _have to_ - but in case your code does it - if the lock is reentrant, it will not cause any problems retaking the lock by the thread that already holds it.
Hi Jakob, the tutorials are great, in fact I can say its the best I have found so far on multithreading. One question I have is for the tryLock() example.
When thread3 is in queue and waiting for 1000ms, does it need to be next in line to be able to lock the Lock or can it be in any part of the queue and will still be able to lock the Lock if the Lock is unlocked during that 1000ms time??
From what you said in the video, I think the thread has to be next in line to be able to lock the Lock but just want to confirm if I understand it correctly.
When in doubt about a detail like this, it can be a good idea to check the official JavaDoc for the given method. There you can often find such details listed. The tryLock() method without a timeout does *not* respect other threads waiting in line to lock the ReentrantLock. The tryLock(timeout) method - the version with a timeout - *does* respect other threads waiting in line to lock the Lock. See the official JavaDoc here:
docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html#tryLock(long,java.util.concurrent.TimeUnit)
@@JakobJenkov Thanks so much!
Checking to see if current thread is queued isn't it unnecessary since the thread will be blocked trying to get the lock. At (26 min)
Are there any difference if you put lock.lock() right before try-finally block and not within try block? For example The art of multiprocessor programming suggest the approach with acquiring lock before entering try block.
There should not really be any difference there... except if lock.lock() can throw an exception you are interested in catching somehow.
Hi Jokob at minute 10:24 lock is called one time in the calculate method. How is it possible to execute add/subtract if the lock was already called without unlock ?
If a Lock is reentrant, a thread can lock the same lock more than once, and yet only one unlock() call is necessart to unlock it.
Is that lock needed for a getter when inc is already synchronized ?
Since reading a variable doesn't change it - synchronization / locking is not necessary to guarantee correct behaviour. However, to guarantee "visibility" of the variable that is protected by the Lock - you should consider locking and unlocking when accessing it (or make the variable itself volatile).
I believe usually we do not apply locks to reading the variables. As per Jacob, I learnt that making writes to variables definately will require locks to perform this kind of operation and also to make it visible what changes you are making, you need to make that variable volatile. Otherwise, there is no guarantee that your changes are shown to other threads also. Hence, usually for a method like setter makes sense to have keyword like synchronized. Correct me if I am wrong, Jacob :) .
Thanks for sharing Jakob. Just wonder if you've covered Condition anywhere?
What exactly do you mean by "Condition" ?
@@JakobJenkov I meant this one docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Condition.html
Im dizzy hearing lock 😵💫
Btw great video.
Thanks 😅
excellent explained
Thank you very much 😊
Hi Jakob, thanks for the wonder explanation!! However, your website is down. Can you please check?
Hi Kaixun, thank you for notifying me! ... the server hosting tutorials.jenkov.com is getting old, and has become a bit unstable unfortunately. This is the 3rd crash within a short time period. I will be moving all the tutorials to jenkov.com soon though (a few are already moved) .
Another question : are there really a benefit when making the count property volatile ?
In this case - no, there is not. The access pattern (check-then-update) means that simply using a volatile variable is not enough - you need the atomicity of a synchronized block, or a critical section guarded by a Lock. However, once you have a synchronized block or a block guarded by a Lock, you no longer need the variable to be volatile - because the synchronized block / Lock guarded block provides the same visibility guarantees as a volatile variable does.
4:30 interesting, i didn't know that finally was stronger than return.
Thank you for the video.
You're welcome !!
great video!
Thanks 😊
Amazing bro
Thanks :-D
Thanks Jacob.
You are welcome! :-)
Whatever expertise.. still he can learn something from you.. I am not sure how can we repay you..
Thanks - I am glad my videos are of helpful to you :-)
3:30 the lock variable needs to be static
No it should not an instance variable because it protects that single object. Otherwise it would lock all objects of that class.
Great!
Thanks :-)
Muy bueno !!.
Gracias 😊
is java lock equivalent to kotlin await？
I don't know Kotin well enough to be able to say, unfortunately!
1:24 lock lock lock lock lock
... followed by unlock unlock unlock unlock ... in that exact sequence ;-)
I understand what you said but still I am in confusion can you explain even better.
You teaching is excellent but I am not able to understand (my fault )...!!!!!
What part exactly is it you still need some help with?
wow..... just wow....
Thanks ! :-)
thank you.
You're welcome !
Lock lock lockalock lokulokulock
;-)
take a shot every time it says lock
It better be a shot of something healthy then ;-)
“LOCK LOCK ”“LOCK THE LOCK ”“LOCK THE LOCK ”“LOCK THE LOCK ”“LOCK THE LOCK ”“LOCK THE LOCK “HE LOCK ””......