Race Condition vs Data Races in Java
HTML-код
- Опубликовано: 5 окт 2024
- Memory corruption vs incorrect programs. Learn more about how race conditions and data races occur.
Channel
----------------------------------
Master difficult programming concepts in few minutes. I try to explain difficult concepts like Java concurrency in simple to understand manner. Explore videos on topics like Spring Boot, Cloud Foundry, Java 8 and more. I am happy to clarify your doubts. Ask me anything in the comments. Also happy to take requests for new videos.
New video added every Sunday.
Subscribe or explore the channel - bit.ly/defog_tech
Current Playlists
----------------------------------
Java Executor Service - bit.ly/exec_srvc
Java Concurrency - bit.ly/java_crncy
Spring Boot 2.0 - bit.ly/spr_boot2
Java 8 - bit.ly/java_8-11
Intellij IDEA Shortcuts - bit.ly/i_idea
Popular Videos
----------------------------------
Executor Service - • Java ExecutorService -...
Introduction to CompletableFuture - • Introduction to Comple...
Understand how ForkJoinPool works - • Understanding how Fork...
Java Memory Model in 10 minutes - • Java Memory Model in 1...
Volatile vs Atomic - • Using volatile vs Atom...
What is Spring Webflux - • What is Spring Webflux...
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 :)
Good Explanation, appreciate your work and effort to provide clear understanding of the logic. Keep it up.
You are the GOD of mutithreading🙏
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!
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.
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
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
Awesome explanation.Thanks
Excellent video. Thanks!
Really good explained, thanks.
Hi @Defog , first of all great content , could you please create something around garbage collections and microservices. TIA.
this is a really good one
Very good ... Thanks
Is there any particular reason you prefer this over a synchronized method or block?
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
Thank you sir!
nice explanation
looking into the code, it seems like int x=0, will have issues in multicore as variable is not volatile.
Good explanation!
What are the tools you use to create these videos?
where do you learn all 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.
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
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.
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)
I just missed this question on an interview rip job offer 😭
oh dear, sorry to hear that :(