Mutex Synchronization in Linux with Pthreads
HTML-код
- Опубликовано: 23 фев 2015
- Demo of using threads in Linux (pthreads) to run very simple processing in parallel. Uses a mutex (pthread_mutex) to synchronize the processing to avoid a race condition.
Topics:
- Timing the process without using threads (Linux time command)
- Switching processing to new threads
- Running multiple threads without a mutex lock (race condition)
- Solving a race condition
- Timing the multi-threaded version
- Common problem when passing arguments to a thread
- Common problem spotting race conditions
Links:
Create a single thread: • pthreads #1: Introduction
Eclipse Setup: • C Makefile Project in ...
Linux programming play-list: • C Makefile Project in ...
Found this video randomly when i am studying for a OS final and noticed that this video is actually made by the professor of my very first computer science course’s at a different school. Enjoyed your lecture just like before:)
You are absolutely amazing at this. Most demo's/tutorials that I've watched C, haven't been too good at clarifying the tidbits like the CPU Scheduling and changing the size of the loops. Absolutely amazing!
Thank, I've got a test on friday (today is monday), and only now I could truly understand Thank you so much!!! Greeting from Brazil!!
Thanks for this. I'm designing a thread-pool and you've given me some insights on what might cause it to run slowly.
I can't explain to you Brian how much these videos are a help to me for my Operating Systems class.
so far you are the only one i managed to listen to for more than 30 seconds without closing the window in disappointment and frustration. Don't fail me now
Love the videos and all the practical information provided, extremely helpful.
Also I found that Amdahl's law is a really simple but effective rule of thumb to think about whether you should use a multi threaded system or not.
Awesome! I did the code in parallel as it was being done in the video.. It was fun and I would never forget it.
Great Video Brian, I wish you would have continued making these on the rest of the topics of synchronization. big Help!
Dr. Fraser thank you so much for uploading this type of content. You'r the boss
Thank you so much for this video. You explained it very well and easy to follow from the basic step to the complicated version.
Thank you Brian for such a detailed explaination
I wish I had found your videos the first time I took the operating systems course. Using them now. Thanks a lot.
haha same here
CharlesBarkleyGG i did and i got a B+!!!
Fantastic! Your lectures are superb. Thank you.
best tutorial on threads that i have seen yet
Nice tutorial! I finally understand synchronization thanks to you!
subscribed!! Great content keep on uploading and sharing knowledge
Nice tutorial, thanks for sharing!
Yo, Dr.Bfraser. Do you have a tutorial for Semaphores ?
Awesome explanation !! Thank you Sir.
Simply superb . Thanks
Thank you so much for this video!
Thank you so much! This is really helpful.
Excellent video, thank you so much!
Oh, I'm learning CMPT300 this term and I just passed by your office in Surrey yesterday lol.
Very useful video, thank you!
After this, I don't need to read my book anymore. Thanks man 👍👍
You da real mvp
One should construct a loop-in-a-loop, the inner loop running for example N = 100 times, the outer loop NUM_LOOP divided by N, and place the mutex outside the inner loop and inside the outer loop. Experiment with different values for N (NUM_LOOP dividable by N).
clair et net ! merci chef
This is a very interesting topic, thank you for the valuable information. Wondering about furexes now (fast user mutexes)... ;-)
thanks a lot! It's much clearer than my school lectures
very educational , thx for sharing
Thank you for explaining that shared variable race condition bug, these are very sneaky bugs that traps novice programmers.
Thanks a lot, this was very helpful...
Thanks for the video.It actually helped me:)
great explanation!!
Thank you. This is very helpful! :)
Wow Thank you Professor.
nice tutorial...helped a lot............
Great work!!!
How can some one dislike this video :/
@Hamad AlMarri if you dont like it, dont watch dude, if you are really that good, make videos and show us what you know instead.
Lovely video
Great video, Brian! Do you have a video on semaphores? It would be very helpful.
Amazing video
it was fun
Great video Dr. , Can u please explain me how to get out off the second race condition that u have mentioned while passing same variable for both the threads.
and do u have a video for Semaphores?
God bless you
nice, thx
good job
Great videos! Thanks a lot! Unrelated question - just curious do you somehow related to 19th century explorer Simon Fraser?))
Thanks allot!can you make video on semaphore as well.?
Beautifully explained could u please do it for semaphore? Thanks.
thanks!
eu te amo mano
13:29 So I need to protect access to sum in _sum_ form of critical section
(don't mind me it's a silly pun)
would defining the whole loop as the critical section and therefore locking the mutex before it and unlockin after be an option? Wouldn't it drastically reduce the time required as we would only lock and unlock twice instead of a billion times? Or would that destroy the concept of multiple threads even if there would be more code other than this loop?
this is so weird.. it takes 3-5 times as long with threads on my machine (without the mutex lock), does anyone have an idea why?
your accent is good we indian understand English ,but we don't really get English accent of foreigner ... I have gone through lots of thread video u r the 2 video which I found use full ...thanks for this video and keep it up doc. .
"but we don't really get English.." should be, ",but I don't really get English... " :/
Okay I don't get it..
Nevermind :)
Hello, I was testing on pthread with your tutorial, and I found out that, what make your thread running so slow is due to pthread_exit(NULL). When I replace it with return NULL, the thread run quite faster.
merci
ur fking amazing man!!!
Nice video. I have a comment, shouldn't be the mutex lock and unlock outside the for statement?, so you don't have to do that amount of syscalls, regards.
Well if we are going this way, we can remove the loop and use multiplication. also we can fold the two threads and use multiplication on the difference. But the point is to clarify the mutex usage :)
If you do that, you are loosing the granularity of critical section. for e.g., why cannot mutex lock be done before creating first thread? then it becomes sequential...
Awesome video!!!
MVP
Hi Dr Fraser. Can you explain why without the mutexes the sum calculated is wrong ( The two threads are complementing each other + 1 and -1 ).
If we consider sum += offset as not an atomic operation.
SUM = 0 //global
Thread 1
temp = sum + 1; // temp = 1
--------------------> context swtich 1 -------------> Thread 2
temp = sum - 1 // temp = -1
well, Here it is !
sum += offset( or say sum = sum + offset) is not a single step task.
task 1 . The Value of sum is read.
task 2. Addition of sum and offset takes place
task 3. Value of sum is written to sum variable(overwrite)
---------------------------------------------------------------------------------
Now, Suppose Thread 1 has read the value of sum when it is 10. and it has added offset with sum. Now it is 11. But before overwriting the value in sum , Thread 2 has just finished its task 3 ... so if Thread 2 has made the value from 10 to 9 by subtracting 1, its work will not be reflected because Thread 1 will put 11 into sum. So for one cycle the task done by Thread 2 is wasted. This thing happens so many times . That is why we encounter this weird value of Sum.
Can you add videos on shared memory access?
so with large numbers, we not suppose to use multi-threads? How does this make sense? Thanks
I may be wrong but wouldnt it be faster to lock the mutex before the loop start and unlock after the loop end ? Its less syscalls and should prevent the race condition just the same will beeing faster ? Correct me if Im wrong
One thing I don't get are atomic operations in C are they the same as pthread_mutex?
what happen if same code run real time system like RTOS...
If you use FreeRTOS you should refer to the FreeRTOS manual and look at the xTaskCreate() function which resembles the pthread_create() call in pthreads. See www.freertos.org/a00125.html
is there a continuous for this .? like #pthread4 ? please direct me the playlist
This is an old video and I can't hope for someone to see this comment and answer, but here goes.
Before you add the mutex system calls, why were you getting the wrong answer for sum? It seems to me that in whatever order you add or subtract 1 from a number, if the total amount of summations and subtractions is the same, then the answer should always be 0. For example, let's say that NUM_LOOPS = 10. The first thread adds 1 three times in a row, then the second thread subtracts 1 two times in a row. The sum is now going to be equal to 1. Then the first thread does the remaining seven additions, so sum is equal to 8 and then the second thread subtracts the final eight times. The sum is 0.
How can you possibly get an answer that is different than 0? Having an answer different than 0 would mean that one of the two threads added or subtracted more than the specified amount in NUM_LOOPS. What am I missing?
That's a good question and I'm not sure I am right but I have a theory. On the processor retrieving, adding, and updating the variable are multiple steps. While the sum variable is being transferred to a register from thread A it may be interrupted by another process due to the scheduler. Meanwhile, thread B updates the sum before thread A completes its computation. So thread A is putting back a value that is stale. Each thread may be retrieving a value for the sum from memory that is either the last value that thread updated or the updated value from the other thread. This would explain why the erroneous answer is not 5M and not -5M but somewhere in between.
This is exactly how a race condition works. Im not sure if im too late on this, but during the rare times in which the first thread hasnt finished executing, and the second thread is spawned, it will retrieve the current value of sum and use that as the starting poiunt of the second thread. Meaning if the first thread was on the 80th loop, it would havee a sum value of 80, and if during this the second thread spawmed, its sum value would start off as 80, and would be returning 80-1 (offset is -1 for start of loop) as its first sum answer
20:07 we spawn the second thread and no problem?! it is problem! because you cannot guarantee that 1st thread started and executed at least few first commands while the 2nd thread starts. Those two are in fact independent events, and it's your supposition that they two will be executed sequentially
Why not put the mutex outside of the loop?
Is mutex run by non root uer?
how about deadlock
Pthread_mutex_lock and Pthread_mutex_unlock are not systemcalls.
I love redheads.
"sum" is an unclear variable name. At first glance you would assume that it is the sum of all terms up to 500000000, it should be called nth_term_at_NUM_LOOPS, or along those lines, perhaps change the other variable names. However, good tutorial, thanks.
Know and easy, please put source code more 100k.
Nice tutorial! You could make the loop considerably faster, by adding the lock and unlock before and after the loop... Like so:
pthread_mutex_lock(&mutex);
for (i = 0; i
This would force one whole loop to complete before the other thread's loop even starts, defeating the purpose of concurrent processing.
this video is not for beginner ..I would suggest first read little bits about thread and then u can come back 2 this nice video...then u don't have to go 2 other video.
+Abhijeet Awari He has three other videos on pthreads in C, and those start from the beginning. People really need to watch those first, and practice writing the code (and then changing it) along with him. It's incredibly instructional.
These videos are really excellent--a true gift to those of use trying to learn this stuff on our own. Thank you Dr. Fraser!
It is a beginner video.
lol what did I just hear at 9:24?
Sounds like ned from south park saying "oh no" very quietly.
I need a counting function to sum the number of likes I want to give this video
nothing but lie
Yo, Dr.Bfraser. Do you have a tutorial for Semaphores ?