Hacker News Reader

Comment by jeffbee | Hacker News Reader

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.

View on HN

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.

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

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.

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.

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?

Reply on news.ycombinator.com