Using a trylock | Introduction to Concurrency in C++

Рет қаралды 3,350

2 жыл бұрын

►Full Series Playlist: • Modern C++ (cpp) Concu...
►Find full courses on: courses.mshah.io/
►Join as Member to Support the channel: / @mikeshah
►Git Repo: github.com/MikeShah/moderncpp...
►Lesson Description: In this lesson I show you the difference between calling 'lock' on a std::mutex and something known as a try_lock. The try_lock will immediately return depending on if the lock was able to become successfully acquired or not, allowing threads to continue their execution.
►KZfaq Channel: / mikeshah
►Please like and subscribe to help the channel!

Пікірлер: 28

@RyantheCanuckpirate Жыл бұрын

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.

@MikeShah Жыл бұрын

Cheers, thank you for the kind words!

@user-mi1rh2zj2x 11 ай бұрын

This has been a great course. I've learned so much thanks for putting this together!

@MikeShah 11 ай бұрын

Cheers, you are most welcome!

@emanuelechiari204 2 ай бұрын

hi this series on threads is wonderful thank you very much and I will subscribe to the channel thanks for your work😀

@MikeShah 2 ай бұрын

Cheers, thank you for the kind words 🙏

@RaniGiro 10 ай бұрын

Great series and a great teacher, subscribed!

@MikeShah 10 ай бұрын

Cheers!

@thestarinthesky_ Жыл бұрын

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

@MikeShah Жыл бұрын

Awesome!

@MikeShah Жыл бұрын

Hehe, you're right!

@thestarinthesky_ Жыл бұрын

@@MikeShah Thank you :)

@IamLupo Ай бұрын

Lately i been implementing these cases in assembly NASM with futex linux system calls. Its intresting to learn to know the details how mutex is been build in the background with all these features.

@MikeShah Ай бұрын

That's awesome -- are you by chance building an operating system or working in embedded? Nice to build these primitives from scratch :)

@IamLupo Ай бұрын

@@MikeShah I am active in game modding. Like right now my main focus is PS2, PS3, XBOX 360. I basically started to wonder how it worked on different architectures. For AMD and Inter on 64-bit there is "lock" assembly where its also nicely manage by your processor. Ofcourse you still need to manage your thread manually with systemcall to the OS. But once thats done you can implement all these funkie mutex cases. Like shared_mutex and lock them. Mostly ChatGPT helps me and give examples. And 9/10 times those cases doesn't work like i have to fiddle arround to make it nicely work with cmake/nasm.

@MikeShah Ай бұрын

@@IamLupo Very cool!

@glowiever 2 жыл бұрын

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 2 жыл бұрын

Multi threaded object rendering will save much of time.

@MikeShah 2 жыл бұрын

@@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.

@Andrei-cv1kn Жыл бұрын

Thanks a lot!

@MikeShah Жыл бұрын

Cheers Andrei!

@TechTricks1992 10 ай бұрын

Please add some videos related to thread pool

@MikeShah 10 ай бұрын

Will add to the wish list -- I have more ideas, just need to finish off some other series :)

@mytech6779 9 ай бұрын

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.

@MikeShah 9 ай бұрын

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)

@ananditabose3569 Жыл бұрын

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

@MikeShah Жыл бұрын

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 }