Multithreading

jenya7

@jenya7 to add to @jsulm
QtConCurrent is it's own module, and offers quite a lot of possibilities.

But, since it's a module you'll have to add it to your project file, that comes with all kind of overhead.

Therefore I suggest for you to look at the (somewhat) new static QThread function of create
QThread *QThread::create

in your particular case, it my be even easier than QtConcurrent

So what the cons of the module? Application size is bigger? Execution time is slower?

J.Hilk

@jenya7 said in Multithreading:

So what the cons of the module? Application size is bigger? Execution time is slower?

Well, with using QtConcurrent, you expand the complexity of your application, and I assume (slightly) longer compile and linker timings.

Application side and runtime speed sole depend on the implementation of the 2 classes. That I can't say.

jenya7

With QtConcurrent::run(ConsoleTask ); console application runs some time (5-10 minute) and then shuts down.

J.Hilk

@jenya7 sounds like a race condition, can you show as the content of ConsoleTask ?

jenya7

@J-Hilk

void ConsoleTask (void)
{
        ch_ptr = fgets(cons_str, 256, stdin);
        if (ch_ptr != nullptr)
        {
           trimmed_str =  Trim(cons_str, TRIM_BOTH);
           COMPARSER_ParseCommand(trimmed_str);
        }
}

int main(int argc, char *argv[])
{
   QCoreApplication a(argc, argv);

   motor_params_file = QCoreApplication::applicationDirPath() + "/motor_params.xml";
   sys_params_file = QCoreApplication::applicationDirPath() + "/sys_params.xml";
   script_file = QCoreApplication::applicationDirPath() + "/script.txt";

   GPIO_Init("/dev/gpiochip0");
   SPI_Init("/dev/spidev0.0");
   UART_Init("/dev/serial0");
   UDP_Init();

  SCRIPT_Load(script_file.toStdString().c_str());

  SYS_ParamInit(motor_params_file);
  SYS_ParamInit(sys_params_file);

    while (1)
    {
       udp_rx_size = UDP_Read(udp_buff_rx, 1024);
       if (udp_rx_size > 0)
       {
           printf("message size = %d \n", udp_rx_size);
           UDP_HandleRecvPacket(udp_buff_rx);
       }

         if(UART_Read())
         {
               COMPARSER_ParseCommand(uart_buff_rx);
         }

          QtConcurrent::run(ConsoleTask);
    }

}

jenya7

Aaaa...I think it should be like this

void ConsoleTask (void)
{
    while (1)  //should be a loop!
    {
        ch_ptr = fgets(cons_str, 256, stdin);
        if (ch_ptr != nullptr)
        {
           trimmed_str =  Trim(cons_str, TRIM_BOTH);
           COMPARSER_ParseCommand(trimmed_str);
        }
    }
}

int main(int argc, char *argv[])
{
         QtConcurrent::run(ConsoleTask);  //start here
        
         while(1)
       {
       }
}

J.Hilk

ok @jenya7

that code had to set in for a moment 🙈

A couple of things are wrong here.

One you already noticed. With an infinite while loopat that place, each cycle a new QtConcurrent::run is created and executed, and you'll eventually run out of memory. Likely the cause for your crash.
Why do you have a QCoreApplication instance, but no event loop? That kind of defeats the purpose and leads to this awkward situation where you have to write your own while loop
ConsoleTask is clearly using member Variables (without a mutex) if they are used somewhere else than that will eventually cause problems
With this approach you'll constantly block one of your cpu cores. Is this really what you want to do ? Don't tell me you want to fix that by using some kind of thread sleep function!

jenya7

@J-Hilk said in Multithreading:

ok @jenya7

that code had to set in for a moment 🙈

A couple of things are wrong here.

One you already noticed. With an infinite while loopat that place, each cycle a new QtConcurrent::run is created and executed, and you'll eventually run out of memory. Likely the cause for your crash.

Why do you have a QCoreApplication instance, but no event loop? That kind of defeats the purpose and leads to this awkward situation where you have to write your own while loop

ConsoleTask is clearly using member Variables (without a mutex) if they are used somewhere else than that will eventually cause problems

With this approach you'll constantly block one of your cpu cores. Is this really what you want to do ? Don't tell me you want to fix that by using some kind of thread sleep function!

The target is an embedded device (RRi 4). So I run in a constant loop some tasks. besides reading from UDP and UART I analize some script and send commands to slaves.
So what is the better option? To open a thread for each task? I don't quite understand where I end up after return a.exec(); in console application, so I did a loop.

J.Hilk

@jenya7

That doesn't really sound like extreme time critical operations (analize some script and send commands to slaves) or are event driven, so that you can react to events(e.g new data arrived) directly without waiting in a while loop for it. QUdpSocket and QSerialPort offer these event driven API's. There's no need for a dedicated thread for them.

The example you posted would probably work exactly the same with a QTimer, and be more cpu friendly.

int main(int argc, char *argv[])
{
   QCoreApplication a(argc, argv);

   motor_params_file = QCoreApplication::applicationDirPath() + "/motor_params.xml";
   sys_params_file = QCoreApplication::applicationDirPath() + "/sys_params.xml";
   script_file = QCoreApplication::applicationDirPath() + "/script.txt";

   GPIO_Init("/dev/gpiochip0");
   SPI_Init("/dev/spidev0.0");
   UART_Init("/dev/serial0");
   UDP_Init();

  SCRIPT_Load(script_file.toStdString().c_str());

  SYS_ParamInit(motor_params_file);
  SYS_ParamInit(sys_params_file);

  //... etc
  QTimer t;
  QObject::connect(&t, &QTimer::timeout, &t, &ConsoleTask);
  t.start(20); //20 ms -> 50 times per second
  
    return a.exec(); //Important the EventLoop MUST run
}

jenya7

@J-Hilk said in Multithreading:

@jenya7

That doesn't really sound like extreme time critical operations (analize some script and send commands to slaves) or are event driven, so that you can react to events(e.g new data arrived) directly without waiting in a while loop for it. QUdpSocket and QSerialPort offer these event driven API's. There's no need for a dedicated thread for them.

The example you posted would probably work exactly the same with a QTimer, and be more cpu friendly.

Sorry for my slow understanding. Where do I place QUdpSocket , QSerialPort and other tasks - before return a.exec();? They will run constantly? Some task I can connect to a timer. But I have a time critical task - gather info from slaves, analyze it and send command based on the info - it should be really fast.

jenya7

Can I find a non-trivial Console Application example to learn how to do it right?

J.Hilk

@jenya7 said in Multithreading:

Sorry for my slow understanding. Where do I place QUdpSocket , QSerialPort and other tasks - before return a.exec();? They will run constantly? Some task I can connect to a timer. But I have a time critical task - gather info from slaves, analyze it and send command based on the info - it should be really fast.

that is correct, a.exec()will spin the QEventLoop and therefore your program will not exit (return from the function call) until you QApplication::quit is emitted.

Can I find non-trivial Console Application example to learn how to do it right?

yes of course, the examples Qt offers should actually be enough. They are compile ready and part of your Qt Installation, if you used the online installer.

For example:
UDP

SerialPort

https://doc.qt.io/qt-5/qtserialport-examples.html

jenya7

Thank you.