Best software architecture approach for a single core system

Question

Objective: Designing a data intensive application(myApp) C++ on Linux/RTOS which runs on a single core cpu, there are also 150 other applications share the same core with high priority than myApp.

How the system looks: more than 150 C++ applications share the same cpu core and most of them have high priority than myApp. myApp get scheduled for 10ms to run and myApp should also sleep for 50ms somewhere during its execution cycle. There are 10 data sources producing data, some data sources produce data during certain system conditions. Most of those APIs provided by data sources are all non-blocking and some of the data intensive sources buffer the data at their end.

where I am: There are several unique data sources which myApp should collect data from. Each of the data collection happens in different functions currently in a sequential manner. myApp collects the data from all these sources(currently 10 sources which include video, textual data). some of the data sources buffer the data up to an extent at their side, and myApp can basically read and copy the buffer using the source APi's and process it by adding some metadata and send to another application which uses the data for n purposes.

What I am observing: Some times certain data collection functions takes more time to complete this causes other data collection gets delayed or missed. Say, myApp get scheduled by OS for 10ms every time and myApp stuck at function1 collecting complete data1. There are other 9 functions which myApp have to execute and collect data from.

Creating additional threads removes the control from myApp as the new thread may or may not get scheduled due to system limitation.

Final Approach: Planning to have a scheduler function which schedule data collection by each of these 10 functions. Allocating an execution time(100ms each) limit and checking the time executed at each API in a collection function and forcing it to return after persisting the collected data and resumes later once again time slice is allocated by myApp scheduler and the control reaches that particular func.

example func:

{ 
  if timeSlice then proceed else return; 
  dataChunk = API_Call1(); 
  if timeSlice then 
      proceed further for next dataChunk collection 
  else 
      persist(data, state) and return; 
}

Let me know your thoughts and suggestions on this Architecture/design approach. Thanks in advance.

Answer 1

First, the number of cores in your system is not an issue that would change your approach. The one relevant thing I get from your story is that data is provided in some buffer that needs to be read in time in order not to miss anything. If you wait for too long, the (ring) buffer will overrun and data will be lost.

So, reading data from that buffer is your number one priority. Processing data is not.

Creating additional threads removes the control from myApp as the new thread may or may not get scheduled due to system limitation

This makes no sense. Control is preemptively removed from your app anyway, regardless the number of threads you use.

The best you can do is create one dedicated thread that reads data from the in-buffer as it arrives. You assign a (relatively) high priority to that thread, meaning that thread will be favored by the scheduler compared to your other threads. You then create a (relatively) low priority thread that processes the data that your high priority thread has set apart for you in memory that you control, which may be a file.

You should know the maximum data rate to determine the time your read thread can safely go to sleep after it cleared the in-buffer. If you do not know this you should at least yield control when the buffer is empty, so not to waste CPU cycles on checking for new data.