I recently started experimenting with std::thread and I tried running a small program that displays the webcam feed in a separate thread and I am using OpenCV. I am just doing this for "educational" purposes. What I noticed was that the thread seemed to keep jumping between cores which striked me as odd since I thought that the overhead of this change would not be worth it from an efficiency/performance side of view. Does anybody know the root/reason for such behavior? Short disclaimer --> I am new to StackOverflow so if I missed something, please let me know.

A snapshot of my system monitor - Ubuntu

#include <stdio.h>
#include <opencv2/opencv.hpp> //openCV functionality
#include <time.h> //timing functionality
#include <thread>



using namespace cv;

using namespace std;

void webcam_func(){
    Mat image;



namedWindow("Display window");

VideoCapture cap(0);

if (!cap.set(CAP_PROP_AUTO_EXPOSURE , 10)){
    std::cout <<"Exposure could not be set!" <<std::endl;
    //return -1 ;
}


if (!cap.isOpened()) {

cout << "cannot open camera";

    }
int i = 0;
while (i < 1000000) {

cap >> image;

Size s = image.size();
int rows = s.height;
int cols = s.width;

imshow("Display window", image);
double fps = cap.get(CAP_PROP_FPS);
//cout << "Frames per second using video.get(CAP_PROP_FPS) : " << fps << endl;

//cout <<"The height of the video is " <<rows <<endl;
//cout <<"The width of the video is " <<cols <<endl;
std::thread::id this_id = std::this_thread::get_id();   
std::cout << "thread id -->  " << this_id <<std::endl;
waitKey(25);

i   ;
std::cout <<"Counter value " <<i <<std::endl; 

    }


}

int main() {

std::thread t1(webcam_func);    

while(true){

}


return 0;

}

CodePudding user response：

The default Linux scheduler schedule tasks (eg. threads) for a given quantum (time slice) on available processing units (eg. cores or hardware threads). This quantum can be interrupted if a task enters in sleeping mode or wait for something (inputs, locks, etc.). waitKey(25) exactly does that: it causes your thread to wait for a short period of time. The thread execution is interrupted and a context-switch is done. The OS can execute other tasks during this time. When the computing thread is ready again (because >25 ms has elapsed), the scheduler can schedule it again. It tries to execute the task on the same processing unit so to reduce overheads (eg. cache misses) but the previous processing unit can be still used by another thread when the computing task is being scheduled back. This is unlikely to be the case when there is not many ready tasks or just greedy ones though. Additionally, some processors supports SMT (aka. hyper-threading). For example, many x86-64 Intel processors supports 2 hardware threads per core sharing the same caches. Context-switches between 2 hardware threads lying on the same core are significantly cheaper (eg. far less cache-misses). Also note that the Linux scheduler is not perfect like most other schedulers. In fact, it was bogus few years ago and not even able to fill all available cores when it was possible (see: The Linux Scheduler: a Decade of Wasted Cores). Finally, note that the (direct) overhead of a context-switch is no more than few dozens of micro-seconds on a mainstream Linux PC so having them every few dozens of milliseconds is fine (<1% overhead).