Is synchronous read the same as asynchronous read + while loop inside Boost Asio?

Question

I'm using Boost Asio for reading my USB data. It works great! But I have some conserns.

I'm using synchronous reading (blocking read) when I want to read an incoming message. The reason why I'm choosing blocking read is because I want to read the message directly when it arrives. I have a feeling that if I'm using asynchronous (Non blocking read) read, then I might loose the first data of the incoming data.

My code for reading data is

// Atomic variable for the thread
std::atomic<bool> dataReceived(false);

// Start a read thread
std::thread readThread([&]() {
    constexpr std::size_t buffer_size = 1024;
    std::array<char, buffer_size> buffer;

    boost::system::error_code error;
    std::size_t bytes_transferred = 0;
    try {
        bytes_transferred = deviceUSB.read_some(boost::asio::buffer(buffer), error);
    }
    catch (...) {}

    if (!error) {
        dataRX.assign(buffer.begin(), buffer.begin() + bytes_transferred);
        dataReceived = true;
    }
});

// Write data
deviceUSB.write_some(boost::asio::buffer(dataTX, size));

// Check if data has been received or timeout has occurred
bool timeout = false;
auto startTime = std::chrono::steady_clock::now();
auto timeoutDuration = std::chrono::milliseconds(timeOutMilliseconds);
while (!dataReceived && !timeout) {
    auto currentTime = std::chrono::steady_clock::now();
    auto elapsedTime = std::chrono::duration_cast<std::chrono::milliseconds>(currentTime - startTime);

    // Check if timeout has occurred
    if (elapsedTime >= timeoutDuration) {
        timeout = true;
        readThread.detach(); // Kill the thread
    }
}

// End the thread
if (readThread.joinable()) {
    readThread.join();
}

And the problem is this line. I don't actually kill the thread, just detaching it.

 readThread.detach(); // Kill the thread

If I detach it, then the thread will still live on. My suggestion is to use a while-loop instead of a thread, together with asynchronous read. If the message does not arrive within a certain limit, then the while loop will end.

Question:

Is asynchronous + while loop

bool run = true;
while(run){
    bytes_transferred = deviceUSB.async_read_some(boost::asio::buffer(buffer), error);
    if(bytes_transferred > 0){
        run = false;
    }
}

the same as synchronous inside Boost Asio?

bytes_transferred = deviceUSB.read_some(boost::asio::buffer(buffer), error);

Answer 1

Is asynchronous + while loop [...] the same as synchronous inside Boost Asio?

The question does not make sense. A while loop doesn't make sense in the context of async_read_some. For starters, async_read_some does not return bytes_read so you cannot use it as the loop condition.

You can of course chain multiple async operations, this is often known as a composed operation. That way your while loop can be mimicked in asynchronous code.

To get fully meta, using coroutines you can again write that as a while loop, even though the execution gets suspended and resumed just like with completion handler chaining.

To your concerns:

Buffering

yes repeatedly posting new async read operations will get you all the data, just like when using blocking reads. That's because serial_port models AsyncReadStream which is documented to be "Buffer-oriented asynchronous read stream". In other words, there is internal buffering. In practice the buffering may take place in kernel/hardware, but it's there nonetheless.

Timeout

This also makes little sense:

readThread.detach(); // Kill the thread

detach() doesn't do that. It just tells the OS you're no longer interested in the thread, but you should be as you are sharing resources with the thread.

You don't voice this as a concern, but you should. There is no useful timeout on a blocking read! The call may simply block indefinitely, and your timeout detection might be useless as a result.

Instead, consider asynchronous read, combined with an asynchronous timer wait. That way you can cancel the read when the timer completes, or cancel the timer when the read completes.

Also consider using a composed read. E.g. your wording "I might loose the first data of the incoming data" gives me the idea that you might want to await multiple "packets" until a message is complete. Instead, you can use asio::[async_]read_until to simply read until the condition is met.

E.g. you can read_until(deviceUSB, buf_, "\r\n") to have ASIO do multiple read_some` operations until the buffer contains the delimiter sequence ("\r\n") or an error occurred.

More complicated forms of framing can be used, like e.g. regular expressions, length-prefixed, control-codes etc. I think I have some examples on this site, looking... This seems close Boost ASIO System timer spurious timeout (at least shows in detail how to use an async timer for mutual cancellation, also async_read_until for more complicated completion condition). Here's an example that reads until ETX: asio_read_some countinue reading to get all data I can't find a more complex example that I seem to remember. I'll add it if I find it later.

Sample

Here's a simple example of what I think a good read call would look like for you:

#include <boost/asio.hpp>
#include <iostream>
namespace asio = boost::asio;
using boost::system::error_code;
using namespace std::chrono_literals;

int main() {
    asio::io_context ioc;
    asio::serial_port deviceUSB(ioc, "something");
    asio::steady_timer timer(ioc, 3s);

    std::vector<char> buf;

    timer.async_wait([&](error_code ec) {
        std::cerr << "Timer completion (" << ec.message() << ")" << std::endl;
        if (!ec) {
            std::cerr << "Timeout expired" << std::endl;
            deviceUSB.cancel(); // cancels any async operation
        }
    });

    async_read_until(deviceUSB, asio::dynamic_buffer(buf), "\r\n",
                     [&](error_code ec, size_t bytes_transferred) {
                         std::cerr << "Read completion (" << ec.message() << ", " << bytes_transferred
                                   << " bytes)" << std::endl;
                         if (!ec.failed())
                             timer.cancel();
                     });

    ioc.run();
}

If you need multiple read operations, you might consider keeping the io context around (e.g. using asio::thread_pool(1)).