I searched this forum and stackoverflow about a statement about safety to use the C++ standard thread support library. And also if it is safe to mix it with Threading Commons. We did some tests with Threading Commons Classes and mixing in std::future, std::mutex, std::condition_variable, std::async, std::this_thread::yield... and so on. All worked great. But we are fully aware that „ok, it works“ is not the right way to think about correctness with regards to multithreading
Regarding this post the Threading Commons Classes are implemented using pthreads. By using this: static_assert(std::is_same::value); we see that the c++ thread support lib is also implemented using pthreads for at least the AXC F 2152 we are using. We assume it is ok to mix std::thread stuff and Threading Commons or just fully rely on std::threads. Is this assumption correct: Is usage of std::thread and so on safe and „allowed“? Is it safe and allowed to mix/use classes like std::future, std::condition_variable etc. with Threading Commons Thread / WorkerThread e.g. for communication between components threads and programs? Thanks, Christian
Hello Christian, yes it is okay to use pure threading. The commons classes only implement an easier to use Interface which we check to be complelty cross playtform on all plcnext targets. It is fine to use pure std in your application. Just keep in mind to choose thread priorities wisely. (dont block the Axio ,PN, ESM priorities etc.) It is still recommended not to spawn/fork/detatch any threads from a Program. This can have a negative impact on your Realtime and might block or cause zombie processes when not handled correctly. It is recommended to setup threads from your Component and mange it there accordingly. [quote]std::future, std::condition_variable etc.[/quote] For stuff like that I would recommend using pure STD and not mix it with the Commons Classes. That way you can use available sources and best practices. You are not forced to use our CommonsClasses for standard procedures. kind regads, Oliver