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 :)
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 👍
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.
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
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
@@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?
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.
@@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.
@@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)
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.
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.
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 :)
You are the GOD of mutithreading🙏
Good Explanation, appreciate your work and effort to provide clear understanding of the logic. Keep it up.
7:43 "innocent-looking code"
Great and in-depth explanation...kudos for the video...
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 👍
Great example of ConcurrentHashMap!
Even if you know the concepts go through his videos and at the end your knowledge level will be at least ++
Wat you said is exactly correct...
if your knowledge is shared among threads, it may lead to race conditions. stay safe
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.
Deepak, your videos are amazing!
Do you upload these slides or provide them for reference?
Not yet. Though I am planning to release them under membership soon (along with code workshops and github code).
Will look forward to it!
@@DefogTech Hey are giving any membership? plus training :-) waitingggggggg
Excellent explanation
Really good explained, thanks.
Is there any particular reason you prefer this over a synchronized method or block?
this is a really good one
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
Awesome explanation.Thanks
What are the tools you use to create these videos?
Excellent video. Thanks!
where do you learn all this ?
Hi @Defog , first of all great content , could you please create something around garbage collections and microservices. TIA.
looking into the code, it seems like int x=0, will have issues in multicore as variable is not volatile.
If we use ConcurrentHashMap we can avoid Data Races ? thanks .
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
Good explanation!
Very good ... Thanks
nice explanation
Hi Deepak, Can data race happen on a volatile variable?
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
@@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?
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.
@@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.
@@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)
How can we avoid Data Race in java for Long/Double?
probably AtomicLong/AtomicReference can be used.
You could use volatile keyword to prevent this.
your are awesome ! Thanks a lot
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.
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.
@@DefogTech Thanks Deepak.. Let me gothrough on this topic, let me try to do some examples on this.
Thank you sir!
I just missed this question on an interview rip job offer 😭
oh dear, sorry to hear that :(