3

I want to be able to freeze and unfreeze a thread at will.
My current solution is done through callbacks and busy waiting with sleep. This is obviously not an optimal solution.

I'm considering having the main thread lock a mutex, then have the slave thread run a function that locks and unlocks the same mutex.
My worry is the possible CPU usage if it's a true busy wait.
My question, as such, is: how does STL in C++11 specify "blocking", and if it is a busy wait, are there less CPU intensive solutions (e.g. pthreads)?

  • Why freeze and unfreeze a thread at will? Get problems when frozen with mutex locked (block other threads). Why not just yield at suitable locations if the algorithm thinks it can let something else have a go? BTW - STL is just a set of concepts that have defined bevaiour. People can implement the STL in a multitude of ways including using `ptheads` – Ed Heal Mar 15 '14 at 03:18
  • Looks like a [XY problem](http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). The fact that you are worried that acquiring a lock might incur in a busy-wait loop is a sign you are probably using the wrong approach to whatever problem you are trying to solve. – DanielKO Mar 15 '14 at 10:44
  • 1
    @Shingetsu sounds like you actually want a [`std::condition_variable`](http://en.cppreference.com/w/cpp/thread/condition_variable). This enables you to notify another thread (e.g. if there is work to do). – stefan Mar 15 '14 at 14:22
  • Essentially, I need to stop rendering of any form in a window to avoid disparity between captured data and displayed data. My old solution was to have a busy waiting loop, and when I wanted to stop freezing it, I simply disconnected the loop end from the start. I'm looking into condition_variable, thanks a lot for that hint @stefan :) –  Mar 15 '14 at 17:33

2 Answers2

3

While mutexes can be used, it is not an optimal solution because mutexes should be used for resource protection (see also this q/a). Usually, std::condition_variable instances are what you should be looking for. It works as follows:

  1. Create an instance of std::condition_variable and distribute it to your controlling thread and your controlled thread
  2. In the controlled thread, create a std::unique_lock. Pass it to one of the condition variable's wait methods
  3. In the controlling thread, invoke one of the notify methods on the condition variable.

Hope that helps.

J. D.
  • 113
  • 13
1

Have a look at this answer: Multithreading, when to yield versus sleep. Locking a mutex (in the manner you've described), is a reasonable solution to your problem.

Here's an MSDN article that's worth a read. Quote:

Until threads that are suspended or blocked become ready to run, the scheduler does not allocate any processor time to them, regardless of their priority.

If a thread isn't being scheduled it's not being run.

Community
  • 1
  • 1
Liam M
  • 5,306
  • 4
  • 39
  • 55
  • ... At the correct locations thus not preventing other threads from working – Ed Heal Mar 15 '14 at 03:21
  • @EdHeal doesn't say that in the question. – Liam M Mar 15 '14 at 03:24
  • The question states "at will". I take that to mean at any point in time. – Ed Heal Mar 15 '14 at 03:26
  • He can yield at any time. – Liam M Mar 15 '14 at 03:27
  • "at will" means at ones desire. That could be half way in working out if condition is true/false. Just like CTRL-Z in UNIX land – Ed Heal Mar 15 '14 at 03:42
  • The author can call yield whenever he likes, in the same manner that he can lock a mutex whenever he likes. Changed my answer to point to another answer that provides a neat summary. – Liam M Mar 15 '14 at 03:44
  • You are not getting it. A line of C++ generates multiple CPU instructions. Can you insert yield somewhere in the middle of that? You cannot without fiddling with the assembly. You can get the OS to interrupt the thread (a signal) to do so - i.e. at will - like sending a signal to a process in UNIX. – Ed Heal Mar 15 '14 at 04:01
  • Yes, I do 'get it'. I also understand interrupts and context switching. You've invented a new question the OP didn't ask are proceeding to change that question for the sake of argument. If you think interrupts are a good solution to the author's simple problem (hint: they're not) then post your own answer. – Liam M Mar 15 '14 at 04:16
  • @LiamM based on the (newest) read, essentially when a thread is blocking while waiting for a mutex to be freed, barely/no CPU is being used (it's essentially yielding until a notify that it's available now). Is this correct? –  Mar 15 '14 at 17:36
  • @Shingetsu When a thread is suspended or blocked it consumes very little - essentially zero - CPU time. I've added a link to my answer that you should have a look at. I've tried to find a link that's as concise as that one for Linux, but I haven't managed to find one. – Liam M Mar 15 '14 at 18:05