At the moment I am using a producer consumer model for the rendering portion of a realtime graphics application. The consumer will continually look for data in our queue(infinite loop); however I am fearful that this may cause my simulation to get out of sync of the main loop. I think this is the fast producer slow consumer problem - compounded by the fact that the simulation is restrained to a certain amount of time.
Question - what is the best method to keep this all in balance and make sure the consumer has enough time to finish, but also that the simulation does not move to the next frame before we are finished rendering our current frame(or at least be able to detect this and skip rendering the next frame - or interrupt the current frame being rendered) I am currently just interrupting and joining after each consumer is finished
Second Question: if you look at the code below you will see that I am currently just calling interrupt and join after adding rendering jobs to the queue - this allows the thread all the time it needs to complete its operation, and to respond to the interrupt when finished. How can I then reuse threads in a thread pool after interrupt_all and join_all are called? (i.e. if i call drawNextFrame again)
The producer is part of the main thread of execution (I don't think this affects anything)
pseudo code:
void renderSystem::init()
create queue to hold work;
create consumer threads of type RenderConsumer set to watch our queue;
add threads to thread_pool of consumers called 'RenderThreads'
void renderSystem::drawNextFrame()
for each thread in 'RenderThreads' divy up work;
add work assignment to queue;
//RenderThreads will now successfully start pulling data from our queue
renderThreads.interupt_all();
renderThreads.join_all();
int main()
renderer = renderSystem class;
renderer.init()
while(not_gameover)
renderer.drawNextFrame();
doOtherCoolStuff();
profit(?)
return(0)
if you need to look at the consumer class see below:
pseudo code:
RenderConsumer::operator () ()
while(true)
try to dequeue from queue
//digest any packet we get
for each ( pixel in packet )
computePrettyStuff()
//we are now done with packet that we got
this_thread::interruption_point();
I tried to make this simple and quick to digest, thank you for your time
#1. I would do this by counting the amount in the queue after each render. If it too high, then either
a. Dump the queue
b. Set a boolean variable to false
That variable will be shared between the threads, and when the producer sees that it is false, it begins waiting on a condition variable. The consumer then notifies the producer when the queue is down to an acceptable level again.
#2. Probably not possible with join_all, as the postcondition to join_all is
Every thread in the group has
terminated.
according to the reference.
It might however be possible, using barriers instead of join_all, but then you would have to find a way to provide them data, which would invariably end up needing some more shared variables.
Related
I have inherited a complex program in my current job and am seeking to reduce image flickering from a stream of data coming over a QTcpSocket.
The program receives the continuous stream of data, processes it, then paints it on the screen with a paintEvent.
The processing function is run based on a signal/slot connection where the signal is readyread() from a QTcpSocket, and the slot is the data processing function. The stream is continuous so this signal/slot is continually firing and updating the painted image on the screen based on the incoming data.
The image flickers constantly, and I assume that the processing in the main event loop could be interfering with the data stream, so my idea was to put the data processing function in its own thread. This data processing function is so thoroughly integrated into the other features of the program, that subclassing the data stream at this point so that I could apply a QThread is not a solution and would be a complete restructure of the entire program, taking tons of time.
So my idea was to use QtConcurrent like so:
void MainWindow::getDataThread(){ //implemented as a slot
wpFuture = QtConcurrent::run(this, &MainWindow::getData);
}
where getData() is the data processing function connected to the readyread() signal:
connect(tcpSocket2, SIGNAL(readyRead()), this, SLOT(getData()));
So I replaced SLOT(getData()) with SLOT(getDataThread()) to allow the data processing function to be run on a new thread that is obtained from the global thread pool. Since the stream is continuous, I believe it is constantly assigning a new thread every time the getData processing function is ran. It does seem to reduce flickering but after about 30 to 60 seconds the program randomly crashes with no specific callouts.
So my question is: Is there a better method for threading my data processing function, without subclassing the data stream? Is my thinking/understanding wrong in my implementation of QtConcurrent in this specific situation?
Thank you.
From your comment I assume your understanding of thread pool is wrong.
There are a number of threads in a thread pool. Each time you call QtConcurrent::run a free thread from the global thread pool is taken and being handed a task to do (MainWindow::getData). If you call QtConcurrent::run several times than every time MainWindow::getData will be executed in (presumably) different thread. If there are no currently available threads in thread pool, you tasks will be queued and handed to threads as they become available later. This way you can have several simultaneous tasks running limited by the number of threads in the thread pool.
Now the problem is, that MainWindow::getData is probably not thread safe by its design. QtConcurrent::run(this, &MainWindow::getData); called several times may result in data race.
If you want a separate single thread to process data then just use QThread (no need to "subclass" anything):
// A thread and its context are created only once
QThread thread;
QObject context;
context.moveToThread(&thread);
// ...
QObject::connect(tcpSocket2, &QTcpSocket::readyRead, &context, [this] () {
this->getData();
}, Qt::QueuedConnection);
thread.start()
Now as long as context object is alive and thread is running each time QTcpSocket::readyRead is emmited - the lambda will be executed.
Still pay attention so that your worker thread and you main thread do not collide in getData.
I can't seem to find an exact answer to the threading question I have. I currently have a program that polls the Kinect V2 sensor for new frame data using OpenNI2. The problem is I need to poll each type of sensor; depth, IR, and RGB separately in order to get them at the same time. Here is where my threading questions comes in, I want to poll each of the three sensors in their own individual thread and when all functions calls have returned continue with the data processing.
I understand how to link each new thread to the main thread to ensure all threads finish before the program exits, but how do I wait in the middle of my program for a specific set of threads to finish? Is there a function or feature of std::thread in c++11 that I am overlooking or is this something that needs to be manually done using a mutex or semaphores?
pseudocode:
std::thread thread_RGB(Kinect::readFrame(Enum::RGB), kinect_1);
std::thread thread_IR(Kinect::readFrame(Enum::IR), kinect_1);
std::thread thread_depth(Kinect::readFrame(Enum::depth), kinect_1);
// Wait for all threads to finish getting new frame data
...
// Process data here
process_data(kinect_1.RGB_data);
process_data(kinect_1.IR_data);
process_data(kinect_1.depth_data);
You need to call .join method to wait for the threads to finish and then destruct them. When you call t.join() there is a check if the thread is still doing something and if the work is done the thread is joined. If the thread is not joinable(there is also t.joinable()) the main thread will wait till the secondary thread finish its work and then join it.
In your case you can add these lines.
thread_RGB.join();
thread_IR.join();
thread_depth.join();
Here is an image I found on google that shows how thread::join() works.
I am writing my first threaded application for an industrial machine that has a very fast line speed. I am using the MFC for the UI and once the user pushes the "Start" machine button, I need to be simultaneously executing three operations. I need to collect data, process it and output results very quickly as well as checking to see if the user has turned the machine "off". When I say very quickly, I expect the analyze portion of the execution to take the longest and it needs to happen in well under a second. I am mostly concerned about overhead elimination associated with threads. What is the fastest way to implement the loop below:
void Scanner(CString& m_StartStop) {
std::thread Collect(CollectData);
while (m_StartStop == "Start") {
Collect.join();
std::thread Analyze(AnalyzeData);
std::thread Collect(CollectData);
Analyze.join();
std::thread Send(SendData);
Send.join();
}
}
I realize this sample is likely way off base, but hopefully it gets the point across. Should I be creating three threads and suspending them instead of creating and joining them over and over? Also, I am a little unclear if the UI needs its own thread since the user needs to able to pause or stop the line at anytime.
In case anyone is wondering why this needs to be threaded as opposed to sequential, the answer is that the line speed of the machine will cause the need to be collecting data for the second part while the first part is being analyzed. Every 1 second equates to 3 ft of linear part movement down this machine.
Think about functionnal problem before thinking about implementation.
So we have a continuous flow of data that need to be collected, analyzed and sent elsewhere, with a supervision point to be able to stop of pause the process.
collection should be limited by the input flow
analyze should only be cpu limited
sending should be io bound
You just need to make sure that the slowest part must be collection.
That is a correct use case for threads. Implementation could use:
a pool of input buffers that would be filled by collect task and used by analyze task
one thread that continuously:
controls if it should exit (a dedicated variable)
takes an input object from the pool
fills it with data
passes it to analyze task
one thread that continuously
waits for the first of an input object from collect task and a request to exit
analyzes the object and prepares output
send the output
Optionnaly, you can have a separate thread for processing the output. In that case, the last lines becomes
passes an output object to the sending task
and we must add:
one thread that continuously
waits for the first of an output object from analze task and a request to exit
send the output
And you must provide a way to signal the request for pause or exit, either with a completely external program and a signalisation mechanism, or a GUI thread
Any threads you need should already be running, waiting for work. You should not create or join threads.
If job A has to finish before job B can start, the completion of job A should trigger the start of job B. That is, when the thread doing job A finished doing job A, it should either do job B itself or trigger the dispatch of job B. There shouldn't need to be some other thread that's waiting for job A to finish so that it can start job B.
My process reads from a single queue tasks that need to be sent to several destinations.
We need to maintain order between the tasks (ie task that arrived in the queue at 00:00 needs to be sent before the task that arrived at 00:01) therefore we cannot use thread pool. Order needs to be maintained per destination.
One solution is to create a dedicated thread per destination. The main thread reads the
task from the queue and depending on the destination finds the correct thread.
This solution has a problem: if a worker thread is busy, the master thread would remain blocked, making the system slow. What I need is a new queue per thread. The master thread
shares the resources to the queues and the worker thread reads the new queues for incoming
messages...
I would like to share my thought with the SO community, and I am searching for a C/C++ solution close to me description. Is there a library that implements such model?
The design you want is fairly straightforward; I think you can probably write the code you need and get it working in an hour or two. Looking for a 3rd party library to implement this is probably overkill (unless I am misunderstanding the problem).
In particular, for each 'worker' thread, you need a FIFO data structure (e.g. std::queue), a Mutex, and a mechanism that the 'master' thread can use to signal the thread to wake up and check the data structure for new messages (e.g. a condition variable, or a semaphore, or even a socketpair that the worker blocks on reading, and the master can send a byte on to wake the worker up).
Then to send a task to a particular worker thread, the master would do something like this (pseudocode):
struct WorkerThreadData & workerThread = _workerThreads[threadIndexIWantToSendTo];
workerThread.m_mutex.Lock();
workerThread.m_incomingTasksList.push_back(theNewTaskObject);
workerThread.m_mutex.Unlock();
workerThread.m_signalMechanism.SignalThreadToWakeUp(); // make sure the worker looks at the task list!
... and each worker thread would have an event loop like this:
struct WorkerThreadData & myData = _workerThreads[myWorkerIndex];
TaskObject * taskObject;
while(1)
{
myData.m_signalMechanism.WaitForSignal(); // block until the main thread wakes me up
myData.m_mutex.Lock();
taskObject = (myData.m_incomingTasks.length() > 0) ? myData.m_incomingTasks.pop_front() : NULL;
myData.m_mutex.Unlock();
if (taskObject)
{
taskObject->DoTheWork();
delete taskObject;
}
}
This will never block the master thread (for any significant amount of time), since the Mutex is only held very briefly by anyone. In particular, the worker threads are not holding the mutex while they are working on a task object.
The "need to maintain order" all-but-directly states that you're going to be executing the tasks serially no matter how many threads you have. That being the case, you're probably best off with just one thread servicing the requests.
You could gain something if the requirement is a bit looser than that -- for example, if all the tasks for one destination need to remain in order, but there's no ordering requirement for tasks with different destinations. If this is the case, then your solution of a master queue sending tasks to an input queue for each individual thread sounds like quite a good one.
Edit:
Specifying the number of threads/mutexes dynamically is pretty easy. For example, to take the number from the command line, you could do something on this order (leaving out error and sanity checking for the moment):
std::vector<pthread_t> threads;
int num_threads = atoi(argv[1]);
threads.resize(num_threads);
for (int i=0; i<num_threads; i++)
pthread_create(&threads[i], NULL, thread_routine, NULL);
I am new to multithreading and have designed a program that receives data from two microcontroller measuring various temperatures (Ambient and Water) and draws the data to the screen. Right now the program is singly threaded and its performance SUCKS A BIG ONE.
I get basic design approaches with multithreading but not well enough to create a thread to do a task but what I don't get is how to get threads to perform seperate task and place the data into a shared data pool. I figured that I need to make a queue that has one consumer and multiple producers (would like to use std::queue). I have seen some code on the gtkmm threading docs that show a single Con/Pro queue and they would lock the queue object produce data and signal the sleeping thread that it is finished then the producer would sleep. For what I need would I need to sleep a thread, would there be data conflicts if i didn't sleep any of the threads, and would sleeping a thread cause a data signifcant data delay (I need realtime data to be drawn 30 frames a sec)
How would I go about coding such a queue using the gtkmm/glibmm library.
Here's a suggestion:
1. Have two threads, that are responsible for obtaining data and placing into a buffer. Each thread has it's own (circular) buffer.
2. There will be a third thread that is responsible for getting data from the buffers and displaying on the screen.
3. The screen thread sends messages to the data threads requesting some data, then displays the data. The messages help synchronize execution and avoid dead-locks.
4. None of the threads should "wait on single or multiple objects", but poll for events.
Think of this scenario using people. One person is delivering water temperature readings. Another person delivering ambient temperature readings. A third person receives or asks for the data and displays the data (on a white board). The objective is to keep everybody operating at maximum efficiency without any collisions.
If you're looking for a lock free implementation of this, you won't find one. When data structures are being written to, something needs to keep two threads from simultaneously updating the data structure and corrupting it.
Is there any reason you can't have each thread collect on it's own, with it's own structure, and then combine the results at the end?