0

I'm learning pthreads after learning about regular threads. Normally when we use a boolean thread object we declare it as a volatile object like this: volatile bool thread_lock;. Do we need to do this on pthread objects as well, specifically on pthread_mutex_t when needed or does it handle it itself?

I've looked up into the pthread_mutex_t declaration and found out that it does not have a volatile declaration.

Should it be volatile pthread_mutex_t my_obj; or pthread_mutex_t my_obj;

Turgut
  • 711
  • 3
  • 25
  • 8
    _Normally when we use a boolean thread object we declare it as a volatile object like this: volatile bool thread_lock;_ ... No we dont. Where did you get this abomination from? – Mike Vine Nov 08 '22 at 11:53
  • 7
    It should be neither, volatile is misused, and means very little in the modern world, since it does not guarantee thread synchronization. Correct usage of mutexes and condition variables eliminates any need for volatile; it's only remaining purpose is to help in chasing the elusive lock-free unicorn fairy, which is very hard to catch. – Sam Varshavchik Nov 08 '22 at 11:53
  • 5
    http://c.isvolatileusefulwiththreads.com is a good reference. – Mike Vine Nov 08 '22 at 11:55
  • @SamVarshavchik Can you write that as an answer please so I can accept it? – Turgut Nov 08 '22 at 12:11
  • 1
    Unless you are on some ancient version of C++ (pre C++11) You shouldn't be learning pthreads, you should be using [std::thread](https://en.cppreference.com/w/cpp/thread/thread), and [std::mutex](https://en.cppreference.com/w/cpp/thread/mutex) and [std::scoped_lock](https://en.cppreference.com/w/cpp/thread/scoped_lock) or std::unique_lock for threadsafety. volatile usually only still has meaning for memory mapped io (embedded devices). – Pepijn Kramer Nov 08 '22 at 12:53
  • @PepijnKramer I'm coding on an embedded device. The reason for me to use volatile is not related to the fact that I'm coding for such devices but it still is a fact. – Turgut Nov 08 '22 at 13:31
  • Does that mean your compiler doesn't support C++11? And I am curious as to why you are using volatile in this case and why you think it is needed. – Pepijn Kramer Nov 08 '22 at 13:51
  • @PepijnKramer you are right I should use c++ mutex variables and I will. However the project is huge and I want to synchronize all classes before converting all of them to c++ 11 threads. Also I would like to learn about them. Curiosity. – Turgut Nov 08 '22 at 14:06
  • 1
    Curiousity is a good thing. The scoped lock is quite important , It allows you to lock when you want and it will automatically unlock the mutex (so you can't forget calls to unlock) – Pepijn Kramer Nov 08 '22 at 14:54
  • @PepijnKramer Thanks! I recently learned that using lock/unlock solves almost all of my problems lol – Turgut Nov 10 '22 at 05:57
  • 1
    You are welcome, resource managment (locks are resources too) are best left to [RAII](https://en.cppreference.com/w/cpp/language/raii). – Pepijn Kramer Nov 10 '22 at 08:24
  • 1
    @Turgut PC programmers are utterly confused regarding this subject. If you ask the question as "should I voltatile qualify a variable shared with a callback/ISR function to prevent incorrect optimizations", then yes probably you should, particularly on various more or less skunky embedded systems compilers. If you ask "should I use volatile for reentrancy purposes" then the answer is no. And if you ask "should I use voltatile for memory barrier purposes" the answer is yes/no/maybe. Although if you use pthreads, your definition of an embedded system seems to be "laptop"... – Lundin Nov 15 '22 at 14:11

1 Answers1

6

Normally when we use a boolean thread object we declare it as a volatile object like this: volatile bool thread_lock;

This use of volatile has never been standard. Some platforms added these semantics to volatile as a regrettable and confusing extension.

More tedious details in another answer, but the short version is that you should never use volatile for synchronization. It's neither necessary nor sufficient.

The POSIX threading library takes care of everything for you - if you needed to write volatile to make it work, it would say that in its manpages and documentation. It doesn't, because you don't.

More portably, C++ has had its own standard concurrency support since 2011, and it's perfectly mature.

Useless
  • 64,155
  • 6
  • 88
  • 132