actually pretty good explanation i completely forgot that subject and you helped to me remember that all thanks! the slides are very clean and subject focus :)
@koushalprasad83135 жыл бұрын
Good Explanation, appreciate your work and effort to provide clear understanding of the logic. Keep it up.
@karishmaauti9332 Жыл бұрын
You are the GOD of mutithreading🙏
@mangeshpawar22555 жыл бұрын
Really appreciate your efforts to provide us very nicely implemented with example video which help us to understand the things very well and in shortly. Thanks buddy 👍
@prasanthrajendran16115 жыл бұрын
Great and in-depth explanation...kudos for the video...
@mrajendhran2 жыл бұрын
Great example! But I have one doubt, how to handle race condition in distributed applications? Like, same service could be deployed in multiple containers... Please consider following statements are in place, 1) Reading data from DB and store it in local variable 2) Data manipulation on local variable 3) Saving updated data into DB.
@shaocongdong27953 жыл бұрын
Great example of ConcurrentHashMap!
@caitlinmclaren26954 жыл бұрын
7:43 "innocent-looking code"
@abhijitrajan9594 жыл бұрын
Even if you know the concepts go through his videos and at the end your knowledge level will be at least ++
@bsaisanthosh15724 жыл бұрын
Wat you said is exactly correct...
@miguelpetrarca55404 жыл бұрын
if your knowledge is shared among threads, it may lead to race conditions. stay safe
@AmNotLegend2 жыл бұрын
this is a really good one
@abrehamish3 жыл бұрын
Excellent explanation
@ratneshchouhan62 жыл бұрын
Hi @Defog , first of all great content , could you please create something around garbage collections and microservices. TIA.
@sean02193 жыл бұрын
Excellent video. Thanks!
@shellindebted53284 жыл бұрын
Awesome explanation.Thanks
@mirageman24 жыл бұрын
Really good explained, thanks.
@parthsatija44135 жыл бұрын
Deepak, your videos are amazing! Do you upload these slides or provide them for reference?
@DefogTech5 жыл бұрын
Not yet. Though I am planning to release them under membership soon (along with code workshops and github code).
@parthsatija44135 жыл бұрын
Will look forward to it!
@vipinkoul91294 жыл бұрын
@@DefogTech Hey are giving any membership? plus training :-) waitingggggggg
@miguelpetrarca55404 жыл бұрын
For the first source code shown, if we had an additional thread that that just gets the value of x, would we possibly have visibility issues where the thread that executes getX() sees a stale value? and not the latest write? depending on whether the value is read from the CPU cache or main memory
@updownftw3 жыл бұрын
where do you learn all this ?
@yoapps1375 жыл бұрын
Is there any particular reason you prefer this over a synchronized method or block?
@arungopi21052 жыл бұрын
What are the tools you use to create these videos?
@bhawanishekhawat23704 жыл бұрын
Very good ... Thanks
@hiamitchaurasia5 жыл бұрын
Good explanation!
@mickeycoreight74813 жыл бұрын
Thank you sir!
@rahulshrivastava30405 жыл бұрын
looking into the code, it seems like int x=0, will have issues in multicore as variable is not volatile.
@Sambitsabyasachi005 жыл бұрын
nice explanation
@alixak43045 жыл бұрын
your are awesome ! Thanks a lot
@ShivManiShivraj5 жыл бұрын
Hi Deepak, Sorry to ask out of topic question. Doubt on immutable objects. -------------- is that true ? ---------------------------------------------------- Q5) What are the advantages of immutability? Ans) Immutable objects are automatically thread-safe, the overhead caused due to use of synchronisation is avoided. --------------------------------------------------------------- Can you explain please.
@DefogTech5 жыл бұрын
Technically thats true. If 2 threads are having their own copies of the object there will be no need for synchronization. Though there is more nuance to this. For eg: 2 threads working on same Person. Even if there are 2 copies, what happens when they want to save it in DB. Or a request comes asking for this Person, which thread should provide the response. Will read up more on this and make a video.
@ShivManiShivraj5 жыл бұрын
@@DefogTech Thanks Deepak.. Let me gothrough on this topic, let me try to do some examples on this.
@diegoramos275 жыл бұрын
If we use ConcurrentHashMap we can avoid Data Races ? thanks .
@DefogTech5 жыл бұрын
Well, data races are practically not a big issue in java. With respect to race conditions, yes, we can avoid that if we use concurrent hashmap
@rajendrakumardangwal80845 жыл бұрын
Hi Deepak, Can data race happen on a volatile variable?
@DefogTech5 жыл бұрын
yes, it can happen.. for statements which check-and-update.. even if 2 threads use a volatile variable volatile int val = 2 t1 = if (val == 2) { val = 5 } t2 = if (val == 2) { val = 7 } to fix this we need to use AtomicInteger and use compareAndSet
@rajendrakumardangwal80845 жыл бұрын
@@DefogTech Thanks for the reply. I just found the book "Topics in Parallel and distributed computing" which clearly states "There is a second way to avoid data races when writing tricky code that depends on the exact ordering of reads and writes of fields. Instead of using locks, we can declare fields to be volatile. *By definition, accesses to volatile fields do not count as data races*, so programmers using volatiles are still upholding their end of the grand compromise". What is the final conclusion?
@DefogTech5 жыл бұрын
As per my understanding data races are when two threads try to set the variable value at same time leading to data integrity issues. Java doesn't have this problem. Race conditions on the other hand cab still happen with volatile.
@rajendrakumardangwal80845 жыл бұрын
@@DefogTech Thanks for the reply. I read the Java Language Specification for volatile keyword. It says, unlike read and write of non-volatile long or double values which can have inconsistent data when written by multiple threads, writes and reads of volatile long and double are always atomic. Also, the volatile read/write introduces the happens-before relation in the execution. So, we can say that access to volatiles can never be in race. By the way thanks for your time and efforts. Your videos are awesome.
@garamburito3 жыл бұрын
@@DefogTech Hi, thank for the video. At some point you can consider the problem of non atomic read/write on long/double in Java, as a Race condition problem. For example: Thread 1 Thread 2 set firsts 32 bit of x read firts 32 bit of x read seconds 32 bit set second 32 bit This is an example of race condition, and can be avoided using the volatile sentence. Therefore, in my opinion the answer is yes, volatile solves race conditions (of this kind)
@momonga.4 жыл бұрын
I just missed this question on an interview rip job offer 😭
@DefogTech4 жыл бұрын
oh dear, sorry to hear that :(
@himanshusukhija68034 жыл бұрын
How can we avoid Data Race in java for Long/Double?