4 ms·

A little disappointing. I was hoping to see lightweight thread behavior or other lessons learned from Go. The ability to pause a thread from outside is interes

by lrossi 6y ago

A little disappointing. I was hoping to see lightweight thread behavior or other lessons learned from Go. The ability to pause a thread from outside is interesting, but it doesn’t seem very useful in general. It also comes with risks. What if it’s holding a lock? That could cause a performance/latency disaster.

jeffbee 6y ago
Any function that returns while holding a lock may be a disaster. That's not specific to threads. This is why you should prefer RAII locked mutexes like std::scoped_lock whenever possible.
- AnimalMuppet 6y ago
  What you say is true, but (as far as I can tell) unrelated to the issue at hand. Yes, if you return holding a lock, it's a potential disaster. And if you pause a thread from outside while the thread is holding a lock, it's a similar disaster. But RAII and scoped_lock won't save you if a thread is paused from outside, since the paused thread never makes it out of the scope that took the lock.
  - jeffbee 6y ago
    You are talking about some theoretical thing that doesn't apply here. There is no facility in std::jthread that allows it to become "paused".
    - AnimalMuppet 6y ago
      Then what was lrossi referring to when he (?) said: >>> The ability to pause a thread from outside is interesting, but it doesn’t seem very useful in general. >>> It also comes with risks. What if it’s holding a lock? That could cause a performance/latency disaster. Which you replied to, not claiming that it couldn't be paused from outside, but instead that the lock risk was just the same as returning from a function.
      - jeffbee 6y ago
        It's difficult to get the point across on the Internet, but lrossi's statement is just nonsense. std::jthread has not introduced any new risks with respect to locking.
        lrossi 6y ago
        You are right, the sleep functions apply only to “this_thread”. What confused me is the comment for the two functions, which refer to the thread as “t” and not “this_thread”; which also matches the naming used for the “is_joinable” function, where it is not the current thread. So I thought it’s a way to do back pressure across threads, which could be useful, but I was clearly wrong. My bad, but also not a great choice of naming things in the original article. Then again, if you can only put the current thread to sleep, why have a function for it? Why not call sleep directly?
nemanjaboric 6y ago
There's a proposal to add fibers (akin to Boost.Fiber) to std C++, and of course, don't forget about coroutines :-)
pavlov 6y ago
C++20 also includes coroutines, which can be used to implement lightweight async behavior without the overhead of a thread.
hueho 6y ago
Lightweight threads like in Go or Erlang are not happening anytime soon as a C++ standard because they require much more complex runtimes to be decently implemented (whereas traditional threads can just delegate straight to whatever OS threading is available). There are coroutines though, that can fill some of the same needs covered by lightweight threads: https://en.cppreference.com/w/cpp/language/coroutines https://en.cppreference.com/w/cpp/language/coroutines

by lrossi 6y ago

jeffbee 6y ago

Any function that returns while holding a lock may be a disaster. That's not specific to threads. This is why you should prefer RAII locked mutexes like std::scoped_lock whenever possible.

AnimalMuppet 6y ago
What you say is true, but (as far as I can tell) unrelated to the issue at hand. Yes, if you return holding a lock, it's a potential disaster. And if you pause a thread from outside while the thread is holding a lock, it's a similar disaster. But RAII and scoped_lock won't save you if a thread is paused from outside, since the paused thread never makes it out of the scope that took the lock.
- jeffbee 6y ago
  You are talking about some theoretical thing that doesn't apply here. There is no facility in std::jthread that allows it to become "paused".
  - AnimalMuppet 6y ago
    Then what was lrossi referring to when he (?) said: >>> The ability to pause a thread from outside is interesting, but it doesn’t seem very useful in general. >>> It also comes with risks. What if it’s holding a lock? That could cause a performance/latency disaster. Which you replied to, not claiming that it couldn't be paused from outside, but instead that the lock risk was just the same as returning from a function.
    - jeffbee 6y ago
      It's difficult to get the point across on the Internet, but lrossi's statement is just nonsense. std::jthread has not introduced any new risks with respect to locking.
      - lrossi 6y ago
        You are right, the sleep functions apply only to “this_thread”. What confused me is the comment for the two functions, which refer to the thread as “t” and not “this_thread”; which also matches the naming used for the “is_joinable” function, where it is not the current thread. So I thought it’s a way to do back pressure across threads, which could be useful, but I was clearly wrong. My bad, but also not a great choice of naming things in the original article. Then again, if you can only put the current thread to sleep, why have a function for it? Why not call sleep directly?

nemanjaboric 6y ago

There's a proposal to add fibers (akin to Boost.Fiber) to std C++, and of course, don't forget about coroutines :-)

pavlov 6y ago

C++20 also includes coroutines, which can be used to implement lightweight async behavior without the overhead of a thread.

hueho 6y ago

Lightweight threads like in Go or Erlang are not happening anytime soon as a C++ standard because they require much more complex runtimes to be decently implemented (whereas traditional threads can just delegate straight to whatever OS threading is available). There are coroutines though, that can fill some of the same needs covered by lightweight threads: https://en.cppreference.com/w/cpp/language/coroutines https://en.cppreference.com/w/cpp/language/coroutines