CODEWITHSUNDEEP
c++multithreading
Sam Gomari
Sam Gomari

Reputation: 765

Multirate threads

I ran recently into a requirement in which there is a need for multithreaded application whose threads run at different rates. The questions then become, since i am still learning multithreading: A scenario is given to put things into perspective:

Say 1st thread runs at 100 Hz "real time" 2nd runs at 10 Hz

and say that the 1st thread provides data "myData" to the 2nd thread.

Upvotes: 0

Views: 110

Answers (2)

Tony Delroy
Tony Delroy

Reputation: 106096

Any multithreaded program has to cope with the possibility that one of the threads will work faster than another - by any ratio - even if they're executing on the same CPU with the same clock frequency.

Your choices include:

  • producer-consumer container than lets the first thread enqueue data, and the second thread "pop" it off for processing: you could let the queue grow as large as memory allows, or put some limit on the size after which either data would be lost or the 1st thread would be forced to slow down and wait to enqueue further values

    • there are libraries available (e.g. boost), or if you want to implement it yourself google some tutorials/docs on mutex and condition variables

  • do something conceptually similar to the above but where the size limit is 1 so there's just the single myData variable rather than a "container" - but all the synchronisation and delay choices remain the same

The Singleton pattern is orthogonal to your needs here: the two threads do need to know where the data is, but that would normally be done using e.g. a pointer argument to the function(s) run in the threads. Singleton's easily overused and best avoided unless reasons stack up high....

Upvotes: 0

Jeremy Friesner
Jeremy Friesner

Reputation: 73081

How is myData going to be provided to the 2nd thread

One common method is to provide a FIFO queue -- this could be a std::dequeue or a linked list, or whatever -- and have the producer thread push data items onto one end of the queue while the consumer thread pops the data items off of the other end of the queue. Be sure to serialize all accesses to the FIFO queue (using a mutex or similar locking mechanism), to avoid race conditions.

Alternatively, instead of a queue you could have a single shared data object (essentially a queue of length one) and have your producer thread overwrite the object every time it generates new data. This could be done in cases where it's not important that the consumer thread sees every piece of data that was generated, but rather it's only important that it sees the most recent data. You'd still need to do the locking, though, to avoid the risk of the consumer thread reading from the data object at the same time the producer thread is in the middle of writing to it.

or does there need to be some kind of decimation to reduce the rate.

There doesn't need to be any decimation -- the second thread can just read in as much data as there is available to read, whenever it wakes up.

Does the myData need to be some kind of Singleton with locking mechanism.

Singleton isn't necessary (although it's possible to do it that way). The locking mechanism is necessary, unless you have some kind of lock-free synchronization mechanism (and if you're asking this level of question, you don't have one and you don't want to try to get one either -- keep things simple for now!)

How about the opposite case, when the data used in one thread need to be used at higher rate in a different thread.

It's the same -- if you're using a proper inter-thread communications mechanism, the rates at which the threads wake up doesn't matter, because the communications mechanism will do the right thing regardless of when or how often the the threads wake up.

Upvotes: 1

Related Questions