Anyway, it is amazing indeed, I also have an suggestion, this video explained the reentrantlock in theory in details, could u plz give me some examples about the real use cases in practice? Like scenarios of online shopping? Thx a lot
Such an amazing explanations in all the videos , you certainly have a crystal clear understanding , and must have put a lot of an effort to understand. Honestly Hats off ....
Awesome explanation. Truly love the way you explain and clear the doubts. Would it be possible for you if you can also make videos of explaining the collections internal structures like how does it work? Thanks
Loved the explanation on covered concepts.. very clear ... But some things are not covered e.g what happens when multiple locks are taken and what is the use case here..
Multiple locks could be taken when you are transferring money between accounts. So, for instance there is a worker thread pool which takes in the requests to transfer money from one account to another account. Here upon getting such request we would need to take locks on both accounts, transfer the money and then release the locks to ensure consistent results. Be careful with how the locks are taken and released. Otherwise we might end up in a deadlock.
Thanks for an amazing video, However I have a question, apart from the recursion you mentioned, are there any practical scenarios where this acquiring the same lock again makes sense
Really awesome explanation .. I was read oracle docs on reentrant locks, it has just two lines of documentation.. I've couple of questions here 1. Can we use synchronized block instead of the reentrant lock If there is a recursive function call ? 2. On the trylock() method, how does setting timeout to 0 would achieve the fairness? Please elaborate
Nice Video, thanks for the informative Video. I have one question. Y we want to acquire the lock more than one time using Reentrant lock.. what is the real usage.??
As per my understanding,this can be undestood in following ways: Lets say, there are two synchronized methods , m1 and m2. Lets say m2 is being called inside m1.Lets say there is a common object whose lock is required to access m1 and m2. Now,Lets say Thread t1 accesses the method m1 first and now while processing m1, it enters inside m2 method also.In this case, t1 is not required to again acquire the lock of that common object as it is already holding that(before entering into m1).As the Thread t1 is reentering inside another Synchronized area , this process is said to be Reentrance(entering again). Now, as far as the Locks are concerned,since we are not using synchronized keyword, we will have to apply one lock in m1 and another in m2.Hence, in this case holdCount is 2 now. Hope this helps.
@@pchandra3277 Correct, thread already has the lock, but when recursively thread calls the function again.. and function has lock.lock() as its first line, then thread needs to increase its lock count (it is just called reentrant lock based on synchronized block primitive). So it doesnt really acquire the lock again, it just increases the lock count.
Great content, but can you share a use-case suitable. as per your example., in real time seat booking, concurrency level is at database/hibernate. Database isolation gives locking mechanism to handle it, so why would i use lock at java level??
Agreed, probably not perfect use case. But even here having locking only at DB level will not help. If 2nd user books same ticket, DB update statement will throw exception. Thus concurrency needs to be handled at java level itself
Correct, that means at Java level the SQL update query code will have to throw exception or return 0. Then Java will have to handle asking user to book another seat. Again, this is not ideal use-case, completely agree. Will think of a better one and let you know.
CAn you please exaplain the following statement by Java docs: fairness of locks does not guarantee fairness of thread scheduling. Thus, one of many threads using a fair lock may obtain it multiple times in succession while other active threads are not progressing and not currently holding the lock.
We shall acieve the same using a boolean variable, right? Like you have explained in "volatile and atomic" video. Can you please tell me any reason why we should not use that boolean way and use reentrant lock way?
I didn't understand the point you said in the video that "when calling method recursively that's we it is reentrant lock" But the same thing will happen with synchronized lock also. On the same object, they are also reentrant(stackoverflow.com/questions/13197756/synchronized-method-calls-itself-recursively-is-this-broken) , so is this is fare to say based upon this point that they are reentrant.
As per your example of recursion ..The current thread count will increase to 2 when it reenter the lock. So lock should also be released Twice....Can you elaborate on this?
I just wanted to ask , if the Reentrant Lock works in the same way as synchronized block , then why does the Thread trying to access the lock unsuccessfully , go into a "waiting" as it suggests in the video. Shouldn't it be in a blocked state just like synchronized does? Thanks
Thanks for the reply. Just wanted to ask , would the specific state for a thread unsuccessfully accessing the lock be the Blocked state. This is the state that the Java API mentions in it Thread Life Diagram.
8:25 a major source of confusion. lock.lock() will cause other threads to get blocked, but when it's called by same thread again (one holding the lock) it doesn't get blocked. This needs explanation.
Hi bro, I have a query, you described tryLock would not block the thread, it just returns true or false based on the lock availability then how come the concept of fairness comes into picture for trylock. Please explain or I misunderstood the logic?
The idea of the reentrant lock when the lock can be called multiple times on the already locked object remains absolutely value and unclear. What's the point to call .lock() multiple times? what exactly happens when you call .lock() again and again?
What is the difference between normal lock object and reentrantlock(false) object. For only fairness purpose should we go to reentrant lock or anyother reason ?
In that case the fairness is not guaranteed by JVM. It may or may not be fair based on workload, other threads in the system and scheduler configuration
Well, thats good point, though what happens when a user tries to book A1 to A10 seats and another user selected A8 to A12... you have to atomically allow or deny seat booking in such overlaps
We should have instances of all the seats in concurrent hash map. Thread pick the seat or an instance of the seat from map and we place lock on that seat instance. If two thread try to lock the same seat which is locked by thread then it should not allow it's booking give some message.
Btw, when we are booking say A1 to A10 tickets... even if locks are in concurrent hashmap, we will have to book each ticket in a for loop (get lock, book, unlock)... when we first check A1 to A10, all seats and locks might be available, but when we actually run the for loop, A1 to A7 will be booked but A8 will give error.. then A1 to A7 will need to be rolled back to unbooked It seems tricky to implement. Single lock per whole chart might be simpler.
Apologies for the uneven audio at the beginning... I am trying out a new microphone. Hopefully will be better by next video
Don't worry it was good explanation, thanks
Please say About lockinterupatability
Anyway, it is amazing indeed, I also have an suggestion, this video explained the reentrantlock in theory in details, could u plz give me some examples about the real use cases in practice? Like scenarios of online shopping? Thx a lot
Must say, awesome explanation
This video is excelent. You are the best, keep going make good videos like this one.
Such an amazing explanations in all the videos , you certainly have a crystal clear understanding , and must have put a lot of an effort to understand. Honestly Hats off ....
Quality compilation of material and simple lucid explanation on this channel. Big shout out to Defog tech.
Can't stop watching. SO good.
The best tutorial to explain reentrant lock and pairness. Thank you, great job!
You're welcome! Thank you for the kind words
pairness?
Good ppl do exist. This guy is a living example.
Thanks a lot, crystal clear explanation.. appreciate your efforts!!!
Very clear and precise explanation,,Definitely worth watching
Nice presentation. Clear explanation.
Very clear and concise. Thank you. Subscribed!
nobody comes close to explain multithreading like you .very nice sir.where do you work
Really defogged my knowledge,Thanks a lot.
I like your presentation to make concept easier to understand
Thank you for creating such wonderful video, kudos
Very good detailed information .
Very clear and simple explanation of the concept...
Excellent explanation. Clear and well articulated.
Awesome explanation. Truly love the way you explain and clear the doubts.
Would it be possible for you if you can also make videos of explaining the collections internal structures like how does it work?
Thanks
sure, though I am slightly busy with work so unable to create new videos, please remind me again soon if I miss this
@@DefogTech Gentle reminder!!
simply outstanding
Extremely good 💯💯💯
Examples are perfect!
Thank you so much. This was great
Fascinating videos!
Lucid explanation. Subscribed.
I absolutely love this channel. Amazing explanation by the creator. Thanks.
like your videos especially on concurrency. Plz create more videos on concurrency
Amazing Content Bro Keep it Up
Your explanation is too good bro i have just small suggestions that please provide a link for you website where from we can read easily this all
Loved the explanation on covered concepts.. very clear ... But some things are not covered e.g what happens when multiple locks are taken and what is the use case here..
Multiple locks could be taken when you are transferring money between accounts. So, for instance there is a worker thread pool which takes in the requests to transfer money from one account to another account. Here upon getting such request we would need to take locks on both accounts, transfer the money and then release the locks to ensure consistent results.
Be careful with how the locks are taken and released. Otherwise we might end up in a deadlock.
Love your explanations. Keep up the good work..:)
Thank you!
Very well done, thank you for the time you put into this.
Thanks Defog.
Thanks it's very helpful
love you bro, you explain so good
Nice Video..#KeepHelpingUs
Thanks for an amazing video, However I have a question, apart from the recursion you mentioned, are there any practical scenarios where this acquiring the same lock again makes sense
great example ..Thanks
I finally understand what ReentrantLock is
Awesome! Good going..
Really awesome explanation .. I was read oracle docs on reentrant locks, it has just two lines of documentation.. I've couple of questions here 1. Can we use synchronized block instead of the reentrant lock If there is a recursive function call ? 2. On the trylock() method, how does setting timeout to 0 would achieve the fairness? Please elaborate
Nice Video, thanks for the informative Video. I have one question. Y we want to acquire the lock more than one time using Reentrant lock.. what is the real usage.??
Good question. I couldn't find the best use case for it either. Only possible scenario seems when we need recursion.
As per my understanding,this can be undestood in following ways:
Lets say, there are two synchronized methods , m1 and m2. Lets say m2 is being called inside m1.Lets say there is a common object whose lock is required to access m1 and m2.
Now,Lets say Thread t1 accesses the method m1 first and now while processing m1, it enters inside m2 method also.In this case, t1 is not required to again acquire the lock of that common object as it is already holding that(before entering into m1).As the Thread t1 is reentering inside another Synchronized area , this process is said to be Reentrance(entering again).
Now, as far as the Locks are concerned,since we are not using synchronized keyword, we will have to apply one lock in m1 and another in m2.Hence, in this case holdCount is 2 now.
Hope this helps.
@@DefogTech Sir , we already have the lock with the working thread, then on recursion senario, why it will be required.?
@@pchandra3277 Correct, thread already has the lock, but when recursively thread calls the function again.. and function has lock.lock() as its first line, then thread needs to increase its lock count (it is just called reentrant lock based on synchronized block primitive).
So it doesnt really acquire the lock again, it just increases the lock count.
you're awesome, thanks!
amazing is the word
Thanks for sharing knowledge.
One of the best explanation about the locks. Could you please also includes the lockInterruptibly() method?
Make a video on ConcurrentHashMap internals, as it uses Reentrant locks on Segments interally.
Great content, but can you share a use-case suitable. as per your example., in real time seat booking, concurrency level is at database/hibernate. Database isolation gives locking mechanism to handle it, so why would i use lock at java level??
Agreed, probably not perfect use case. But even here having locking only at DB level will not help. If 2nd user books same ticket, DB update statement will throw exception. Thus concurrency needs to be handled at java level itself
DB will not allow second update statement because that record will be locked by first transcation.
Correct, that means at Java level the SQL update query code will have to throw exception or return 0. Then Java will have to handle asking user to book another seat.
Again, this is not ideal use-case, completely agree. Will think of a better one and let you know.
Great explanation, Thank you
Very Informative.....One question, What is Read/Write Reentrant Locks? Could you please elaborate or create videos if possible?
Sure, it's on the list.. publishing this Friday
Very well explanation.Awesome keep it up .Subscribed User ++.
CAn you please exaplain the following statement by Java docs: fairness of locks does not guarantee fairness of thread scheduling. Thus, one of many threads using a fair lock may obtain it multiple times in succession while other active threads are not progressing and not currently holding the lock.
Good content and explanation.Thank you.
you're very welcome sir!
We shall acieve the same using a boolean variable, right? Like you have explained in "volatile and atomic" video. Can you please tell me any reason why we should not use that boolean way and use reentrant lock way?
I didn't understand the point you said in the video that "when calling method recursively that's we it is reentrant lock"
But the same thing will happen with synchronized lock also. On the same object, they are also reentrant(stackoverflow.com/questions/13197756/synchronized-method-calls-itself-recursively-is-this-broken) , so is this is fare to say based upon this point that they are reentrant.
Yes, absolutely. Synchronized keyword based locks are also Reentrant in nature
As per your example of recursion ..The current thread count will increase to 2 when it reenter the lock. So lock should also be released Twice....Can you elaborate on this?
Awesome
What would be the the real world usecase where you would hold lock multiple times and calling lock method inside a recursive function?
Awsome boss
just want to confirm small doubt. when one thread locked using lock() method then other threads should have state blocked not Waiting. correct?
Excellent tutorial. I have one question, Doest it work for distributed systems?
You mean different JVMs? No, it wont.. its for multiple threads within single JVM
@@DefogTech Yes, Thanks
I just wanted to ask , if the Reentrant Lock works in the same way as synchronized block , then why does the Thread trying to access the lock unsuccessfully , go into a "waiting" as it suggests in the video. Shouldn't it be in a blocked state just like synchronized does? Thanks
I use the term waiting state even for threads entering synchronized blocks. Basically threads are parked aside waiting for something to happen
Thanks for the reply. Just wanted to ask , would the specific state for a thread unsuccessfully accessing the lock be the Blocked state. This is the state that the Java API mentions in it Thread Life Diagram.
@Defog Tech, are these PPTs available somewhere, which is used in video?
8:25 a major source of confusion. lock.lock() will cause other threads to get blocked, but when it's called by same thread again (one holding the lock) it doesn't get blocked. This needs explanation.
thank you so much
thanks bro...
I have doubt; tell more about trylock with timeout? I didn't get it properly.I mean what's actually use of it.
can you please explain the StampedLock in Java 8 ?
Hi bro, I have a query, you described tryLock would not block the thread, it just returns true or false based on the lock availability then how come the concept of fairness comes into picture for trylock. Please explain or I misunderstood the logic?
Thanks!
Thank you so much for the monetary appreciation. Means a lot to me!
@Defog Tech can you please explain line of code where you use "->" --- what does it mean?
lambda expression introduced in java 8 :)
The idea of the reentrant lock when the lock can be called multiple times on the already locked object remains absolutely value and unclear. What's the point to call .lock() multiple times? what exactly happens when you call .lock() again and again?
What is the difference between normal lock object and reentrantlock(false) object. For only fairness purpose should we go to reentrant lock or anyother reason ?
Lock is an interface, implementation is Reentrant lock.. this for basic lock functionality we can't use Reentrant lock
I do not see where and how you attach a lock to a shared resource: fine, you do lock.lock() but on what object?
Do you have any video on concurrent hashmap?
Not yet, I am making one right now, about differences between maps in Java
Ur writing l.lock(),but on which object it will try to get the lock??
Does only reentrant lock works with recursive functions... what will happen if i try to use some other implementation of lock in a recursive method ?
yes recursive functions with reentrant lock is good! If lock is not reentrant, the recursive function will become deadlocked
How many locks are available for RenetrantLock
12:31 even without setting fair as true can we achive fairness?
In that case the fairness is not guaranteed by JVM. It may or may not be fair based on workload, other threads in the system and scheduler configuration
@@DefogTech
I meant in work around example in which you created an unfair lock.
Thanks for you reply.
Lock should be maintained per seat not to the whole seat chart. Please suggest
Well, thats good point, though what happens when a user tries to book A1 to A10 seats and another user selected A8 to A12... you have to atomically allow or deny seat booking in such overlaps
We should have instances of all the seats in concurrent hash map. Thread pick the seat or an instance of the seat from map and we place lock on that seat instance. If two thread try to lock the same seat which is locked by thread then it should not allow it's booking give some message.
Overlapping case will be interesting to solve with this approach
Makes sense.. worth a try implementing
Btw, when we are booking say A1 to A10 tickets... even if locks are in concurrent hashmap, we will have to book each ticket in a for loop (get lock, book, unlock)... when we first check A1 to A10, all seats and locks might be available, but when we actually run the for loop, A1 to A7 will be booked but A8 will give error.. then A1 to A7 will need to be rolled back to unbooked
It seems tricky to implement. Single lock per whole chart might be simpler.
I guess, that other threads go into BLOCKED state, not WAIT state on slide 1:10
Tutorials are very much informative but unable to digest fastly getting confused
hawahawwai :D
Is there any PDF tutorial present for the same
Not yet. I am planning to include it in a course I am making