How to properly handle shared hardware resources?

[DeveloperPaul123]

We are currently experimenting with qcoro for use in our hardware control software. Typically, our software communicates with hardware via commands where a command or query is sent, and then a response is received and processed.

Previously, we were doing this via a "heartbeat" where we repeatedly call a slot at a given interval (using a QTimer) which will send a "default" command to get some status info from the device.

At time, we also need to send explicit commands to the device (to turn something on or off for example). How can we reliably use coroutines sharing the same communication port and maintain the periodic checks while also being able to send arbitrary commands? Is there a better strategy we should be using?

[danvratil]

I think the coroutines are a good solution for this - consider that whenever a QCoro coroutine is suspended, the execution returns to caller (so, usually the Qt event loop). Thus you can have as many "service" coroutines as you want and always only one is executing at a time, the others are suspended (as long as everything is single-threaded, of course) - same as Qt slots.

If I understand your description correctly, a fictional Comm class might look something like this:

// Heartbeat coroutine
QCoro::Task<> Comm::heartbeat() {
    QTimer sleep;
    sleep.start(1s);
    while (mSocket->open()) {
        co_await sleep;
        const auto stats = co_await command("default");
    }
}

// Sends a command and waits for response
QCoro::Task<QByteArray> Comm::command(const QByteArray &command) {
    mSocket->write(command);
    co_await mSocket->waitForReadyRead();
    // Don't use readAll() in real code as that might eat up multiple pending responses
    // Real implementation depends on your protocol design.
    co_return mSocket->readAll();
}

void Comm::start() {
    // Start the coroutine from the event loop
    QMetaObject::invokeMethod(this, &Comm::heartbeat, Qt::QueuedConnection);
}

void Comm::stop() {
    // Causes the heartbeat coroutine to terminate at latest in 1 second (next time the timer wakes up the
    // coroutine) - tthis might need som extra "synchronization"
    // as you definitely want to make sure the coroutine ends before destroying the Comm object.
    mSocket->close();
}

Regarding sending commands, it's safe to do so (as long as you are on the same thread as the other coroutines), since either the command() coroutine is running, or the heartbeat coroutines is running (or the event loop is just looping), there's no chance of a race. With serial port, I think it's also safe to assume that even if you send "Command A" immediatelly followed by "Command B" you will first receive "Response A" and then "Response B".

Hope this helps.

[danvratil]

You could store the returned Task and then use QCoro::waitFor() - this shoudl work in theory, but I did not test it :-)

void Comm::start() {
  mHeartbeatTask = heartbeat(); // starts the coroutine, doesn't wait for it to finish, though
}

void Comm::stop() {
    mSocket->close();
    QCoro::waitFor(mHeartbeatTask);
}

When moving the window around, there's likely a lot of events that keep the event loop busy, but there should still be enough time to schedule one or two small tasks (heartbeat etc.).

Running coroutines on a separate thread is easy - just make sure they are dispatched from the thread's event loop and they will all run in that thread's context.

[DeveloperPaul123]

I tried your approach but this resulted in a deadlock for me. But maybe I did something wrong 🤔 I'll have to investigate again.

[DeveloperPaul123]

I tried it again and it seems to work as you suggested. I must have done something wrong previously. Thanks!

[danvratil]

Yay 🎉 I'll turn that into a testcase if I haven't already, just to be sure ;-)

[DeveloperPaul123]

Sounds good, thanks again!