Hey mate where have you been the last months. I wanted to thank you you videos are the best for c intermediate level learning plus i was wondering if you are planning on doing some socket programming in c for linux
QQ: First thread enters the routine1 and then takes the lock. Now unless this thread calls unlock on this lock, how can any other thread enter the critical section(as another thread has the lock and in the critical section)?? But, in your case I see a lot of 'Current value is:.." printed in the console. Am I missing something here? Guess: Is even this is a part of undefined behaviour?
could you make at least one video with an exercise where you combine the use of semaphores and mutexes? In my classes they tend to put problems like that in exams >_
This one does use both: code-vault.net/lesson/tlu0jq32v9:1609364042686 But I will look into making more such videos! Think of semaphores as a way to control how many times a certain type of action can be executed. Mutexes are simply used to protect a part of memory from being accessed by multiple threads at the same time
Semaphore maintains a queue for all those threads that tried to enter the critical section when the semaphore variable is 0. So every thread gets a chance in the end in a fair manner (FIFO). While mutex doesn't provide such functionality, and randomly wakeup the thread. Is my statement correct?
Hi, I have tried in my lab to unlock a mutex in a different thread and it was working completely fine for me. But when I create a mutex with type as PTHREAD_MUTEX_ERRORCHECK, unlocking in different thread throws error in return code. Now my question, 1. How unlocking a normal(default init ) mutex in different thread works fine for me. Any possible reasons ? I tried with while (1) loop to lock in in thread and unlock in another thread for 2 hrs and did not see any issue in it.
"1. How unlocking a normal(default init ) mutex in different thread works fine for me. Any possible reasons ?" It's undefined behaviour. Meaning that there's a chance that, what you did right there, might work, but it's never guaranteed to work on every machine.
When the semaphore value is initialised to 0 and a thread called sem_post() thrice, then the value of the semaphore becomes 3? When initialised to 0, should it be called as binary semaphore or counting semaphore?
Sir Please create video on shared memory and Pls tell how to read particular length data From the shared memory, i went through everywhere like stack overflow etc didn't get my answer please explain..
That's interesting. I tested it and it doesn't break on my side either. Could be something MacOS specific although its documentation specifies that it should fail if the thread unlocking it didn't lock it: developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/pthread_mutex_unlock.3.html#//apple_ref/doc/man/3/pthread_mutex_unlock
@@CodeVault yeah I am pretty sure its the MacOs or the chip. There are actually quite a few things that does not happen when I am watchin your videos on multithreading, semaphores, etc when I code it on my machine
This channel is a life saver.
Your explanation is really good and clear with code examples. Thank you so much!
Your explanation is so GREAT!
Thank You & we will absolutely wait for new things to learn from you.
Concepts detail description are nice 🙂
Thank you so much for this video. It was very knowledgable.
Brilliant explanation with illustration
Undefined behavior almost cost me my OS HW thank god for resubmission
Today I understood clearly with practical example.Thank you...
Excellent lesson. Brilliant teacher!
Thank you for this video It cleared diff between Binary semaphore and Mutex
THANK YOU! for making this!
Hey mate where have you been the last months. I wanted to thank you you videos are the best for c intermediate level learning plus i was wondering if you are planning on doing some socket programming in c for linux
I have been busy, I will get back to making videos some day. Socket programming is on the top of my list
thank you for making these!
A very very thank you for this informative video
nice explanation
This is good. Thanks.
Great video! Thanks
Great work.....👍👍👍
Please do tutorials on GLib (Gnome)......
If possible suggest tutorials.....
What exactly would you like to see? glib is quite a large library
It's been along time hope you are doig ok teacher 😇
Thanks for video
you're goated
QQ: First thread enters the routine1 and then takes the lock. Now unless this thread calls unlock on this lock, how can any other thread enter the critical section(as another thread has the lock and in the critical section)?? But, in your case I see a lot of 'Current value is:.." printed in the console. Am I missing something here?
Guess: Is even this is a part of undefined behaviour?
Yes that's undefined behavior. You're not supposed to lock and unlock mutexes from different threads. If you need that, just use semaphores
could you make at least one video with an exercise where you combine the use of semaphores and mutexes? In my classes they tend to put problems like that in exams >_
This one does use both: code-vault.net/lesson/tlu0jq32v9:1609364042686
But I will look into making more such videos!
Think of semaphores as a way to control how many times a certain type of action can be executed.
Mutexes are simply used to protect a part of memory from being accessed by multiple threads at the same time
siraaa veere
Semaphore maintains a queue for all those threads that tried to enter the critical section when the semaphore variable is 0. So every thread gets a chance in the end in a fair manner (FIFO). While mutex doesn't provide such functionality, and randomly wakeup the thread. Is my statement correct?
There isn't any waiting queue mentioned in the documentation. The order in which threads at a semaphore continue is not defined
Hi,
I have tried in my lab to unlock a mutex in a different thread and it was working completely fine for me.
But when I create a mutex with type as PTHREAD_MUTEX_ERRORCHECK, unlocking in different thread throws error in return code.
Now my question,
1. How unlocking a normal(default init ) mutex in different thread works fine for me. Any possible reasons ?
I tried with while (1) loop to lock in in thread and unlock in another thread for 2 hrs and did not see any issue in it.
"1. How unlocking a normal(default init ) mutex in different thread works fine for me. Any possible reasons ?"
It's undefined behaviour. Meaning that there's a chance that, what you did right there, might work, but it's never guaranteed to work on every machine.
When the semaphore value is initialised to 0 and a thread called sem_post() thrice, then the value of the semaphore becomes 3? When initialised to 0, should it be called as binary semaphore or counting semaphore?
Really, it's however you want. For the semaphore API a binary semaphore is no different than a counting semaphore
Sir Please create video on shared memory and Pls tell how to read particular length data From the shared memory, i went through everywhere like stack overflow etc didn't get my answer please explain..
I will look into it!
Thank you sir please check it
in case the semaphore value is greater than 1 and multiple threads are executing the critical section will it lead to a race condition?
Yes! That's why you might see both semaphores and mutexes used in the same context
but how you lock one thread function and then the other function can be executed if the first lock is not already unlocked?
That's the idea, you can't lock the mutex in one thread and unlock in the other
Why did the code even executed for a while? It should have break in the beginning itself
Well... it's undefined behaviour. So an overflow probably occurred somewhere or something accessed memory that it shouldn't
for some reason my mutex code is not breaking? don't know if this has to do with the new M1 mac ARM chips or not
That's interesting. I tested it and it doesn't break on my side either. Could be something MacOS specific although its documentation specifies that it should fail if the thread unlocking it didn't lock it: developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/pthread_mutex_unlock.3.html#//apple_ref/doc/man/3/pthread_mutex_unlock
@@CodeVault yeah I am pretty sure its the MacOs or the chip. There are actually quite a few things that does not happen when I am watchin your videos on multithreading, semaphores, etc when I code it on my machine
What are those exactly? I wanna to test them if possible
4:25