I know it seems strange but 0 == success in BLE (also 14 in NimBLE) anything else is an error value. So this should be give(0) or just give().

Actually this method should probably be refactored a bit since we always return a copy of m_value .
Something like:

{
    m_semaphoreReadCharEvt.take("readValue");
    std::string value = m_value;
    m_semaphoreReadCharEvt.give();

    if(timestamp != nullptr) {
        *timestamp = m_timestamp;
    }

    return value;
}

I wrote it like that on purpose. If we change it to your suggestion there is a little chance that the return value and the timestamp do not belong together, if a notification is in the middle of an update.

I do not like the extra copy of the value but I could not come up with another way. Do you?

Making a copy is necessary but the compiler should optimize it to copy directly into the callers container.

Also now that you mention the timing issue, we have no protection in the notification handler against the value being updated as getValue() is copying. The semaphore would only block if readValue() was called at the same time, but that would be odd.

Of course we cannot take a semaphore in the notification handler unless it was used with a 0 timeout then tested for success, but then we wouldn't be able to update the value if it failed.

I am a semaphore zero and you a h(2z)ero+e, what would you suggest?

Can we come up with a reason for this?

My first thought is when we change the value in notify it creates a new string object and just changes the location pointer of m_value. If the copy constructor was called in getValue() at the same time it would still get a valid reference, at least until the original m_value destructor is called, which could be long enough to finish the copy. I could be completely wrong, worth testing though.

The other possibility is flawed testing 😄, I just realized the peripheral did not vary the data length so my test never went out of range.

If the copy constructor was called in getValue() at the same time it would still get a valid reference, at least until the original m_value destructor is called, which could be long enough to finish the copy

I do not know how FreeRTOS switches tasks. We're not interrupt based, interrupts may occur everywhere. But maybe the OS has some mechanism to protect for the segfaults? idk...

As far as I know it does not have any such mechanism. It simply switches between tasks on a priority basis, when one task is done or waiting for an event it switches to the next highest priority task. Interrupts are handled as their own, highest priority, task that stops all others I believe, but it's been a while since I got into that.

I have come up with a compromise for this, I'll push it to this PR right away, stress testing for a hour now without a problem. It uses the same semaphore with a 0 timeout in the notify callback, that does not update the value if it fails to take it, but that should only happen when reading directly at the same time, so it should not be an issue 99.99% of the time.

If you could test it later on your setup and let me know I'd really appreciate it.

If you could test it later on your setup and let me know I'd really appreciate it.

Sure! But most likely not today because I am busy at the office. Tomorrow for sure!