Really clear! Thanks, concurrency is a bit more complicated of a topic than a lot of other things in my CS program, so it's a good thing to see videos of.
nice. I'm learning multithreading for game engine. would you please share practical use of threading, if possible in that particular subject? thanks mike.
@@jugalshah8199 @Glowie Most game engines opt for a few dedicated threads for each main subsystem (graphics, sound, AI, etc.) and some sort of job system to spawn tasks. Cooridnating can be a challenge. That said, later on in the series it may be worth showing how to have a few dedicated threads in a game work together.
Great Lesson. Thank you so much. At the end that misspell didn't get fixed @14:59 :)) For RAII, I think we can use std::defer_lock instead too in this situation with std::unique_lock. like the following: I hope that's correct: #include #include #include struct SharedResource { SharedResource() : mtx(), counter(0) { } std::mutex mtx; int counter; }; void job1(SharedResource& sharedResource) { std::unique_lock lock(sharedResource.mtx); std::cout
What are these locks really doing down at the assembly or hardware level? I mean is it a just a bool with an if statement?(which seems like a rather heavy solution) Maybe something like a register with a flag (a core register would be too local, but this sort of mechanism). Or maybe some clever logic trick like using two pointers, one to the shared resource and one to null and switching them to lock/unlock and a null dereference would be interpreted as locked.
Effectively a 'test and set' operation is performed for a mutex. Then with a trylock, there is an additional 'condition' as you noted on where to proceed. A regular lock might 'spin' and continue to try to acquire the lock otherwise (i.e. seeing if we can test and set a value)
why would you use a try_lock when you can achieve this with a condition_variable i.e wait for the notify_all() for the consumer and other producers to obtain the lock again
condition_variable has blocking behavior. try_lock you may want to try and move on, and perhaps revisit the lock (e.g. while(true){ do some code ... try lock ... proceed forward in loop to something else, then try again later }
really good playlist. would like to see more related videos on this.
Cheers!
This has been a great course. I've learned so much thanks for putting this together!
Cheers, you are most welcome!
Really clear! Thanks, concurrency is a bit more complicated of a topic than a lot of other things in my CS program, so it's a good thing to see videos of.
Cheers, thank you for the kind words!
hi this series on threads is wonderful thank you very much and I will subscribe to the channel thanks for your work😀
Cheers, thank you for the kind words 🙏
Great series and a great teacher, subscribed!
Cheers!
nice. I'm learning multithreading for game engine. would you please share practical use of threading, if possible in that particular subject? thanks mike.
Multi threaded object rendering will save much of time.
@@jugalshah8199 @Glowie Most game engines opt for a few dedicated threads for each main subsystem (graphics, sound, AI, etc.) and some sort of job system to spawn tasks. Cooridnating can be a challenge. That said, later on in the series it may be worth showing how to have a few dedicated threads in a game work together.
Great Lesson. Thank you so much. At the end that misspell didn't get fixed @14:59 :))
For RAII, I think we can use std::defer_lock instead too in this situation with std::unique_lock. like the following:
I hope that's correct:
#include
#include
#include
struct SharedResource
{
SharedResource() :
mtx(), counter(0)
{
}
std::mutex mtx;
int counter;
};
void job1(SharedResource& sharedResource)
{
std::unique_lock lock(sharedResource.mtx);
std::cout
Awesome!
Hehe, you're right!
@@MikeShah Thank you :)
What are these locks really doing down at the assembly or hardware level? I mean is it a just a bool with an if statement?(which seems like a rather heavy solution) Maybe something like a register with a flag (a core register would be too local, but this sort of mechanism). Or maybe some clever logic trick like using two pointers, one to the shared resource and one to null and switching them to lock/unlock and a null dereference would be interpreted as locked.
Effectively a 'test and set' operation is performed for a mutex. Then with a trylock, there is an additional 'condition' as you noted on where to proceed. A regular lock might 'spin' and continue to try to acquire the lock otherwise (i.e. seeing if we can test and set a value)
Please add some videos related to thread pool
Will add to the wish list -- I have more ideas, just need to finish off some other series :)
why would you use a try_lock when you can achieve this with a condition_variable i.e wait for the notify_all() for the consumer and other producers to obtain the lock again
condition_variable has blocking behavior. try_lock you may want to try and move on, and perhaps revisit the lock (e.g.
while(true){
do some code
...
try lock
... proceed forward in loop to something else,
then try again later
}
Thanks a lot!
Cheers Andrei!
hope u see clion ide