如何将现有功能放入其自己的连续（循环）线程并将更新的参数传递给它？

Question

I have an OpenCV console application that is taking in camera frames from a port and displaying them to the screen, with optional image processing routines done on them first. The main() loop is continuous, ie using while(true), and on each pass it gets a new image that's waiting for it to place into a Mat. I need to maintain at least a 30fps rate in main() so incoming frames are not dropped.

Usually this is not a problem unless I have intense processing, but when I do I'd like to at least offload some of the simpler routines to their own threads so they don't hog linear CPU time. They can run independently by "grabbing" any frame and acting on it, and display their results asynchronously to main(). For example a histogram routine, and a routine that computes global contrast/offset adjustment values.

I've seen a simple example using < thread > syntax where 3 routines are launched in their own threads within main(), they run independently, then are all rejoined at the end of main(), then execution stops. That example is below, and I have incorporated method 1 into my app since it looks simplest. (I have no idea what lambda is).

// CPP program to demonstrate multithreading using three different callables.
#include <iostream>
#include <thread>
using namespace std;

// A dummy function
void foo(int Z)
{
  for (int i = 0; i < Z; i++) {
    cout << "Thread using function pointer as callable\n";
  }
}

// A callable object
class thread_obj {
public:
  void operator()(int x)
  {
    for (int i = 0; i < x; i++)
      cout << "Thread using function object as callable\n";
  }
};

int main()
{
  cout << "Threads 1 and 2 and 3 operating independently" << endl;

  // This thread is launched by using function pointer as callable
  thread th1(foo, 3);

  // This thread is launched by using function object as callable
  thread th2(thread_obj(), 3);

  // Define a Lambda Expression
  auto f = [](int x) {
    for (int i = 0; i < x; i++)
      cout << "Thread using lambda expression as callable\n";
  };

  // This thread is launched by using lamda expression as callable
  thread th3(f, 3);

  // Wait for the threads to finish
  // Wait for thread t1 to finish
  th1.join();

  // Wait for thread t2 to finish
  th2.join();

  // Wait for thread t3 to finish
  th3.join();

  return 0;
}

For a single pass thread, I can do the above and it makes sense. But I want a thread that gets invoked and given several dynamic input parameters (including a Mat and some int/double/bool values) that normally change with every loop around main(). I want the thread stay open and be "re-triggered" every loop and produce new results. These results can remain within the thread (as with the histogram which only displays to an independent window) or they can consist of a few computed values that get passed back to main() for use elsewhere (as with a contrast/offset routine). But in no case do the results need to be synchronized to what main() is doing.

For example a threaded histogram routine would get the Mat image, some rescaling values, and some Boolean controls that tell it to start processing the image data into a histogram and display it with imshow().

If I put the whole histogram routine into a while(true) loop then the thread never terminates, but then I need to have it see the parameters changing so it executes again and I don't know a good way to do this. I'm guessing that it's unnecessary nor elegant to use globals, plus I'm unsure about thread-crossing. Also I'm confused about whether I should be passing literals into it or use pointers/addresses (* and &) to minimize memory shuffling.

Does anyone have a simple clear example of doing such a thing. Preferably using < thread > if at all possible. I'm not an expert coder so please don't go into esoterics or jargon only developers would understand. Thanks much!

Answer 1

I'm not sure if I have well understood what you want to do but I guess you want to launch threads whose the parameters values are updated each "iteration", right ?

If so, you can declare the parameters in you main() function and give them by reference to your threads. The main() function will perform the update and that way, the threads will take it into account.

Something like that:

//...
void foo (int &a, bool &stop) // pass by reference
{
    while(!stop)
    {
        // Do something with a
    }
}
void bar(char &c, bool &b, bool &stop) // pass by reference too
{
    while(!stop)
    {
        // Do something with c and b
    }
}
//...
int main()
{
    std::atomic <bool> stop_threads(false);

    // declare your parameters (and initialize them the way you want)
    int param1(0);
    char param2('a');
    bool param3(false);

    // launch your threads
    thread th1(foo, std::ref(param1), std::ref(stop_threads));
    thread th2(bar, std::ref(param2), std::ref(param3), std::ref(stop_threads));

    // Update the parameters in your while loop
    while(/* Your stop condition */)
    {
        // Update the value of param1, param2 and param3
        // ...
    }

    // When exiting the while loop, the process is ended (no more data to process)
    stop_threads = true;

    th1.join();
    th2.join();

    return 0;
}

I added an additional boolean in parameters of each function to be launched in differents threads in order to have them to stop properly at the end.

I hope this is what you was looking for :)
Don't hesitate to tell me if I have misunderstood your problem.

---

EDIT:

I forgot to mention a very important thing. Every times I wrote "Do something with that variable..." or "Update the value of that variable", you need to use a mutex mechanism over the shared variables (mutual exclusion) in order to avoid different threads accessing the same variable at the same time. And I have changed the bool stop_threads by std::atomic <bool> stop_threads to avoid race condition with the stop flag shared by all threads.

Answer 2

I thinks there is some confusion to what exactly the threads are doing in your example and what you want to do.

Just to clarify, you have a main() method, which is invoked repeatedly, in which you need to do some processing? You would like to put this processing in threads which (for a speed boost?) relies on some data that changes every time main() is called?

If this is the case, then using the threads in such a way will still be "hoging linear CPU time" . This is because join() will wait for the threads to finish. So in this example, three threads are dispatched to do some work. The execution in main() will pause until the three threads are complete. I`ll try and illustrate with the below picture.

--- main thread -----|-----|-----|--wait^--wait^ --wait^------return.
                     **T1**|*****|return^      ^       ^
                           **T2**|*******return^       ^
                                 ***T3***********return^

This pattern is still useful for processing lots of information quickly. The three threads are spawned (re-launched or whatever) every main() call and are used to process information in parallel. The threads must also finish every main call. This is a common pattern for graphics/ information processing.

So for what you want to do and using method one for threads, simply create a function for every individual thread you want to spawn (with whatever parameter types you need), then create a thread with that function and pass it the parameters you need to process.

If you need to communicate results in between threads or back then this is an entire other can of worms. You need to do some research into mutexes or even futures or other means of passing information around with threads to avoid race conditions

If you need to spawn separates threads that are not re-joined in main and run independently then this is another much larger can of worms. I think the provided pattern is more useful than having multiple separate threads.

Answer 3

I discovered the .detach() operation and came up with something that seems to work, at least when I run my entire code I get seemingly very stable operation, I don't notice runaway memory or processor utilization, and everything opens/closes/terminates without error. I put pseudocode below to demonstrate the gist of it.

Does the detach() operation ensure that each thread destroys itself when done? I'm not proud of using globals but this is a first attempt that so far lets me run full speed (30fps). I have noticed that my total time around the main() loop is greatly reduced using these threads, such that time is now dominated by waiting for the next webcam image to be ready, as expected.

//  ...

// globals
bool g_histodone = true;
string g_histwindow = "histogram";
Mat g_webcamImage;


// thread routine
void histogram(Mat Image, double offset, double gain, bool agc)
{
  Mat scaledImage;

  if (agc) {
    resizedImage.convertTo(scaledImage, -1, 1, offset);
    resizedImage.convertTo(scaledImage, -1, gain);
  }
  else
    resizedImage.copyTo(scaledImage);

  // compute histogram image
  // ...

  // display it
  imshow(g_histwindow, histImage);

  // notify main()
  g_histodone = true;
}


void get_webcam_image(void)
{
  // put images into g_webcamImage (actually a group of rotating buffers) as they come in from webcam
}


int main(int argc, const char *argv[])
{
  bool agc = true;
  bool histo = false;
  bool histwindow_not_destroyed = false;
  double offset = 0;
  double gain = 1;
  Mat localImage;

  thread th_capture = thread(get_webcam_image); // start thread to get webcam images
  thread th_histo = thread(histogram, localImage, offset, gain, agc); // start thread for histogram display

  while (true) {

    // wait here to grab the next camera image from buffers and put it into a local Mat
    g_webcamImage.copyTo(localImage);


    // do some optional processing to determine gain/offset (would be its own thread too)
    if (agc) {
      offset = result 1 from agc thread
      gain = result 2 from agc thread

      // apply scaling to the Mat
      localImage.convertTo(localImage, -1, 1, offset);
      localImage.convertTo(localImage, -1, gain);
    }

    // compute and show histogram
    if (histo) {
      if (g_histodone) { // previous thread is finished, start another
        g_histodone = false;
        if (th_histo.joinable())
          th_histo.join();
        th_histo = thread(histogram, localImage, offset, gain, agc);
      }
    }
    // clean up
    else if (histwindow_not_destroyed) {
      destroyWindow(g_histwindow);
      histwindow_not_destroyed = false; // handshaking
    }

    // ...

    // get user keyboard input
    if (key-to-toggle-histogram-pressed) {
      histo = !histo;
      if (histo)
        namedWindow(g_histwindow, WINDOW_AUTOSIZE); // only want window to appear when enabled
      else
        histwindow_not_destroyed = true; // handshaking
    }
    else if (key-to-toggle-agc-pressed)
      agc = !agc;
    else if (key-to-terminate-app-pressed) {
      th_capture.detach(); // terminate the webcam capture thread
      if (th_histo.joinable())
        th_histo.join(); // terminate the histo thread
      return 0;
    }

  }

}

Regarding Fareanor's approach, that looks like a better way as it passes the values into a single thread like I meant to do but didn't know exactly how to do it; I didn't know a thread if declared outside of the while() loop could automatically see the variables as they update (is this because the thread is using the address not the literal value?) I was guessing that variables passed in statically only at the time a thread was declared. So that's good to know, I'll give it a try.

Any advice on how to get variables passed back from a thread into main(), such as my computed agc gain and offset values? If I declare a struct containing two doubles, then should this work?

thread th_agc(agcparams = calc_agc, localImage);

where calc_agc is my routine of type struct_agcparams for the thread, localImage is the Mat, and agcparams contains the gain/offset doubles I'm trying to pass back.

or is it like this?

agcparams = thread th_agc(calc_agc, localImage);

Answer 4

I'll post a new answer in response to your additions. You should add you edits to the question rather than an answer so it is less confusing for people who land on this page.

There is a lot of things you are asking about multi-threaded environments which have no simple answers. What you are talking about is a hard problem. You want some amount of threads to process information that is updated by the original thread. Then you want to be able to share this information back to the original thread.

Firstly, detach() does not ensure the thread cleans up or is stopped. What it does is allow a thread object to go out of scope (destroyed) whilst allowing the actual thread to continue executing. This can be really dangerous with run away threads that never stop amongst other problems.

Secondly, for variable visibility and using a thread object, the thread can see the variables since it takes a reference as its parameters. The thread constructor you are using takes a function and the parameters the function requires. In Fareanor's answer the functions takes a reference. The variable is in scope of the original main() thread and the function being executed by the thread has a reference to this variable. That is why both threads can see and update that variable. There is no need to 'pass it back' as main() and the thread have the same variable. Although this will lead to race conditions. What happens when one thread is in the middle of writing to the variable and the other one reads it?

There are heaps of problems that are going to arise when using threads in this manner without synchronization. Is it really worth the effort? If so you should do some research and play with some good only examples of multi-threaded applications.

To summarize the main problem you going to face (excluded the aforementioned race conditions) is that you have no control over what each thread is executing and when. Your OS will decide this using a scheduler and context shifting. There is no guarantee that a spawned thread will execute its code in a way that coincides with you main thread. For example your execution may look like this.

Legend: - queued for execution, * Executing, R read, W write
MAIN: ****W*****W*****W-------------------***R***R***R***
T1  : -----------------***R**----------------------------
T2  : -----------------------**R***R**W------------------
T3  :----------------------------------------------------

Main could loop several times and write to variables multiple times before the others even do anything. A thread can read the value of a variable but then its execution is queued before it gets a chance to write (T1). A thread may read a variable twice but it was not updated by main in between reads (T3). We can have thread that is not executed for a period of time (T4). When you have independent threads without synchronization, nothing is guaranteed about the order of execution and how much will be executed.