Java ReentrantLock - fairness, tryLock and more

[@DefogTech]

Apologies for the uneven audio at the beginning... I am trying out a new microphone. Hopefully will be better by next video

[@fredyoba]

Don't worry it was good explanation, thanks

[@nithishreddy9056]

Please say About lockinterupatability

[@thomassun3046]

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

[@kirtigupta8450]

Must say, awesome explanation

[@dandantin]

This video is excelent. You are the best, keep going make good videos like this one.

[@learnlearn8230]

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 ....

[@spaarks84]

Can't stop watching. SO good.

[@jackofnotrades15]

Good ppl do exist. This guy is a living example.

[@vilaspaskanti]

Quality compilation of material and simple lucid explanation on this channel. Big shout out to Defog tech.

[@sbylk99]

The best tutorial to explain reentrant lock and pairness. Thank you, great job!

[@DefogTech]

You're welcome! Thank you for the kind words

[@aqwandrew6330]

pairness?

[@madanmohanpachouly6135]

Thanks a lot, crystal clear explanation.. appreciate your efforts!!!

[@mohammedzaid3829]

Very clear and precise explanation,,Definitely worth watching

[@abdulrahmanelrawas2029]

Very clear and concise. Thank you. Subscribed!

[@Kc-nn8mn]

I like your presentation to make concept easier to understand

[@rahulseetharaman4525]

Excellent explanation. Clear and well articulated.

[@narayanadhurti1603]

Really defogged my knowledge,Thanks a lot.

[@parveznawaz99]

Nice presentation. Clear explanation.

[@suhani091088]

Very clear and simple explanation of the concept...

[@parthec1]

Thank you for creating such wonderful video, kudos

[@amitanshupattanayak9065]

Love your explanations. Keep up the good work..:)

[@DefogTech]

Thank you!

[@sureshchaudhari4465]

nobody comes close to explain multithreading like you .very nice sir.where do you work

[@sukhendurana89]

I absolutely love this channel. Amazing explanation by the creator. Thanks.

[@MadMax-sj5fl]

Extremely good 💯💯💯

[@konfinoyair]

I finally understand what ReentrantLock is

[@DefogTech]

Awesome! Good going..

[@sauravsrivastava7229]

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

[@DefogTech]

sure, though I am slightly busy with work so unable to create new videos, please remind me again soon if I miss this

[@aaron9178]

@@DefogTech Gentle reminder!!

[@tedthebed7877]

Lucid explanation. Subscribed.

[@omkarkulkarni9202]

Thanks!

[@DefogTech]

Thank you so much for the monetary appreciation. Means a lot to me!

[@easternadventures9978]

Very well done, thank you for the time you put into this.

[@harshchaudhary8182]

Very good detailed information .

[@VIJAYKAUSHIKTYAGI]

love you bro, you explain so good

[@TheNeethz]

like your videos especially on concurrency. Plz create more videos on concurrency

[@monjasonsteng7861]

Thank you so much. This was great

[@samirallahverdi4948]

Examples are perfect!

[@anirudhgoutam6401]

Amazing Content Bro Keep it Up

[@dvsingh]

simply outstanding

[@surajtiwari9078]

Very well explanation.Awesome keep it up .Subscribed User ++.

[@prashantranjan4859]

Thanks it's very helpful

[@custardapple5031]

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..

[@cromagnon0101]

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.

[@vbar-ukr]

Fascinating videos!

[@shellindebted5328]

Good content and explanation.Thank you.

[@DefogTech]

you're very welcome sir!

[@narendra_ingle]

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

[@AakashKumar-by1jt]

Nice Video..#KeepHelpingUs

[@vilaspaskanti]

Make a video on ConcurrentHashMap internals, as it uses Reentrant locks on Segments interally.

[@nazeelak1]

Great explanation, Thank you

[@guruprasadrao7]

you're awesome, thanks!

[@06A21A0409]

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.??

[@DefogTech]

Good question. I couldn't find the best use case for it either. Only possible scenario seems when we need recursion.

[@sagarshekhar6296]

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]

@@DefogTech Sir , we already have the lock with the working thread, then on recursion senario, why it will be required.?

[@DefogTech]

@@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.

[@kbhardwaj1989]

Thanks for sharing knowledge.

[@SandeepPatel-wt7ye]

One of the best explanation about the locks. Could you please also includes the lockInterruptibly() method?

[@BhawaniSingh-jc7cw]

great example ..Thanks

[@ganeshradiga]

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

[@harshadakhandekar4607]

Thanks Defog.

[@sharanyarai378]

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??

[@DefogTech]

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

[@sharanyarai378]

DB will not allow second update statement because that record will be locked by first transcation.

[@DefogTech]

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.

[@princelowienalasa8776]

can you please explain the StampedLock in Java 8 ?

[@vivekdarji6440]

just want to confirm small doubt. when one thread locked using lock() method then other threads should have state blocked not Waiting. correct?

[@technologiesstepbystep6237]

@Defog Tech, are these PPTs available somewhere, which is used in video?

[@rajeshg3570]

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

[@jozi_mob]

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

[@DefogTech]

I use the term waiting state even for threads entering synchronized blocks. Basically threads are parked aside waiting for something to happen

[@jozi_mob]

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.

[@vinitsunita]

What would be the the real world usecase where you would hold lock multiple times and calling lock method inside a recursive function?

[@venkataramanan2381]

12:31 even without setting fair as true can we achive fairness?

[@DefogTech]

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

[@venkataramanan2381]

@@DefogTech I meant in work around example in which you created an unfair lock. Thanks for you reply.

[@deepakchauhan25583]

amazing is the word

[@sagarshekhar6296]

Very Informative.....One question, What is Read/Write Reentrant Locks? Could you please elaborate or create videos if possible?

[@DefogTech]

Sure, it's on the list.. publishing this Friday

[@AbhishekVaid]

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.

[@ahamedabdulrahman]

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?

[@tarun7597]

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.

[@786PrvN]

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.

[@DefogTech]

Yes, absolutely. Synchronized keyword based locks are also Reentrant in nature

[@mohammadfraz5808]

Do you have any video on concurrent hashmap?

[@DefogTech]

Not yet, I am making one right now, about differences between maps in Java

[@aashoorajput6500]

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?

[@balakrishnajangita6638]

Awsome boss

[@tuananhtran7518]

thank you so much

[@TonyStark-lv4ff]

@Defog Tech can you please explain line of code where you use "->" --- what does it mean?

[@8951348050]

lambda expression introduced in java 8 :)

[@sarojsahoo8763]

How many locks are available for RenetrantLock

[@sudarshanv9797]

I have doubt; tell more about trylock with timeout? I didn't get it properly.I mean what's actually use of it.

[@hyperborean72]

I do not see where and how you attach a lock to a shared resource: fine, you do lock.lock() but on what object?

[@vijayakumarvj]

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?

[@RajKumarSingh-it5sn]

Excellent tutorial. I have one question, Doest it work for distributed systems?

[@DefogTech]

You mean different JVMs? No, it wont.. its for multiple threads within single JVM

[@RajKumarSingh-it5sn]

@@DefogTech Yes, Thanks

[@manideepkumar959]

Ur writing l.lock(),but on which object it will try to get the lock??

[@SivaKumar-cx7db]

Awesome

[@akhilstksa5736]

thanks bro...

[@AruneshSrivastava]

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 ?

[@DefogTech]

yes recursive functions with reentrant lock is good! If lock is not reentrant, the recursive function will become deadlocked

[@chaitanyapl]

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 ?

[@DefogTech]

Lock is an interface, implementation is Reentrant lock.. this for basic lock functionality we can't use Reentrant lock

[@hyperborean72]

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?

[@DeepakPandey-ij3bz]

Lock should be maintained per seat not to the whole seat chart. Please suggest

[@DefogTech]

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

[@DeepakPandey-ij3bz]

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.

[@DeepakPandey-ij3bz]

Overlapping case will be interesting to solve with this approach

[@DefogTech]

Makes sense.. worth a try implementing

[@DefogTech]

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.

[@AndreySaroul]

I guess, that other threads go into BLOCKED state, not WAIT state on slide 1:10

[@akankshamittalsinghal]

Is there any PDF tutorial present for the same

[@DefogTech]

Not yet. I am planning to include it in a course I am making

[@kirankumar-oe5fz]

Tutorials are very much informative but unable to digest fastly getting confused

[@binoydeka810]

hawahawwai :D