I like the way you visualize every concept! A picture speaks a thousand words. I'm looking forward to Basic Java interview videos, more distributed systems videos, Apache tomcat architecture, spring boot and spring basic intros!!!
@饶泽海4 жыл бұрын
You are a talented teacher - thank you very much!
@hyperborean723 жыл бұрын
(almost) crystal clear explanation of the differences
@mahendharb53036 жыл бұрын
Great channel I'm sharing this channel to my colleagues also
@DefogTech6 жыл бұрын
Thank you for the support!
@RohitKumar-hx9ur4 жыл бұрын
one of the best stuff found till date. gone through all concurrency videos it is awesome. suggest u to create same in other topics like JVM , OOPS , EXCEPTION HANDLING in real-time.
@marcinkurek29505 жыл бұрын
Very informative, thank You!
@naveensharma98345 жыл бұрын
Nice information, good to know being a java developer. Though I want to ask how these locks will behave when its multi server application. I meant when book seat requests can go on any server. Lets say (R - Request , S - Server) R1 -> S1 R2-> S2 R3-> S3 so on (All are writer threads) And all these server will access same db/seatchart.
@DefogTech5 жыл бұрын
Good question. Java locks cannot help with that use-case. We will need to use DB locks or some kind of distributed locks like from Redis
@vhxhao3 жыл бұрын
Nice and simple explanation!
@hyperborean724 жыл бұрын
@6:20 why do you call readResource/writeResource on an instance of the class? why not to make those methods static? in case of ReentrantLock you had that method static
@vbar-ukr3 жыл бұрын
Awesome explanation!
@atmiksoni58595 жыл бұрын
Please preparte video on transacation and propagation and also some algorithm
@sharanyarai3786 жыл бұрын
Please clarify why would i need read lock or any lock when i am not going to change the state of object/shared resource?
@DefogTech6 жыл бұрын
If other thread is modifying the state, the thread reading the state can get incorrect value / partial value (not stale value) because writing a field is not atomic operation. This even for reading a read lock it's required
@NexusWorldPulse5 жыл бұрын
Superb and Informative ....thank you !!!
@shivendratiwari32382 жыл бұрын
Please make a video on Object and Class Level Locking
@protyaybanerjee50513 жыл бұрын
So, in the code path, that allows to read state, why would I need to have LOCKS in there ? That's an overhead. Can you explain with an example ?
@sagarshekhar62966 жыл бұрын
As per the video, it is clear that in ReadWrite Lock, one or more threads can read simultaneously and only one thread can write at a time. My concern is, why is it said to be ReentrantReadWriteLock instead of simply ReadWrite Lock.?
@DefogTech6 жыл бұрын
Because same as Reentrant lock with this lock also, the thread can re-enter the block when it already owns the lock
@AmanGarg956 жыл бұрын
Thank you. Helpful.
@DefogTech6 жыл бұрын
You're welcome! Happy it helped
@aneksingh44965 жыл бұрын
Can u please make a video on Stamped Lock
@_abhishekmj_3 жыл бұрын
How do they do in BookMyShow ? We can both read and update at same time ..
@hyperborean724 жыл бұрын
can you please explain why Reentrant Lock does work only when all the thread write to the same resource? Is this the condition - they all have to write? or the condition - they all have to do the same operation (it can be read as well)?
@maybeyesterday2 жыл бұрын
shouldnt the locks be static, am i wrong?
@azeemmohammed62845 жыл бұрын
Can u explain event driven with debezium and push the changes to elastic search
@dowlathbashag655 жыл бұрын
Hi , I have an query about ReadWriteLock, this lock implemented internally for ConcurrentHashMap. Please let me know which lock mechanism used internally for ConcurrentHashMap is it Reentrant or ReadWriteLock...?
@kripamishra81476 жыл бұрын
At time 8:25...we are having a thread2 which is reading a resource r1 and thread4 which is writing resource r1.. is there any chance that thread 5 which wants to read r1 can read different values.. so thread4 modified r1 with value 5, while thread2 still has value 4..then what value thread5 will be reading (4 or 5)..
@DefogTech6 жыл бұрын
thread 2 and thread 4 both want to read r1, thus are allowed to acquire read lock simultaneously. After this, thread 3 will be allowed to write to r1 then thread 5 will be allowed to read r1, which will get the latest value (written by thread 3)... while thread 2 and 4 will read the value before thread 3. due to java memory model, thread will always read the latest value of r1 after acquiring the lock
@av983 жыл бұрын
Sir, come back.
@debbh2743 жыл бұрын
Fantastic
@TheGurukrushna3 жыл бұрын
Kudos
@Sobioytccc5 жыл бұрын
which book have you use to study concurrency .
@DefogTech5 жыл бұрын
Concurrency in practice by Brian Goetz
@Sobioytccc5 жыл бұрын
Thank you dear
@mr.bikashdeka71175 жыл бұрын
@@DefogTech That is old version. Do we have any latest version of Concurrency in practice by Brian Goetz
@shiyuwang4 жыл бұрын
awesome!
@praddybishti6 жыл бұрын
awesome video . Just one question , how can we achieve multiple reads and 1 write simultaneously ? I mean if its not possible with readWrite lock , then do we have any other way/concept through which we can acheive this . Thanks. Btw your videos makes lot of sense to me.
@DefogTech6 жыл бұрын
Reading and writing simultaneously is not possible, I mean to get correct results and maintain data integrity you have to do one thing at a time
@vipinkoul91294 жыл бұрын
Awesome :-) do you teach by any chance , pls let me know. Can i get in touch with you?
@DefogTech4 жыл бұрын
hey Vipin.. no I don't do courses yet. only KZbin videos once in a while
@vipinkoul91294 жыл бұрын
@@DefogTech Awesome course, shows your level of knowledge :-)
@devanampriya1791 Жыл бұрын
god of concurrency
@AleksandarT104 жыл бұрын
Make some more great videos!
@99393645662 жыл бұрын
but why readLock is even created? I mean, if multiple threads can access the lock, then why have it in first place?
@DefogTech2 жыл бұрын
As per Java memory model, if you dont access objects through locks, you can get stale value from cache, so its important in multi-threading to use locks even for reads.