Welcome to lwrb Discussions!

[MaJerle]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[dazwin]

Hi MaJerie,

Having a lock-free ring buffer is great, but having an off-by-one buffer size available to write creates unnecessary fragmentation and is unusable for anything that needs more then byte alignment (e.g. DMA transfers). Given that lwrb_get_free() returns len-1 and the buffer is always uint8_t, I don't see a way around this.

My use case goes even further. I don't know my frame size until runtime, although I can guarantee my reads and writes will be multiples of the same denominator (e.g. if I write in blocks of 16, I know I can read in blocks of 16 as well).

Wouldn't it be better to forego an additional byte in the in the lwrb structure and add a flag to indicate the buffer is full?

[MaJerle]

If we implement flag to indicate "buffer full", then original idea of the buffer is lost. This introduces second operation, (setting the flag, or clearing it) and same operation must be done between read and write. Then we need atomicity on multiple operations in a sequence, making stdatomic not really useful for the library, but we need to introduce rather platform specific way to lock the interrupts (or mutexes).

If you know at runtime the frame size, you can make your array length of x * frame_size and you will be fine.
If you have fixed memory allocation of (let's say) 1k bytes, then you can readjust the size you pass to the buffer init function.

[dazwin]

I definitely don't want to lose the lock-free mechanism!

However, even if I make my array length x * frame_size at runtime, my first block will be x * frame_size - sizeof(uint8_t) - that's the problem!

Thinking about about this, if I write to the buffer and discover that there's less than a full frame remaining, I'd could skip over those remaining bytes and start from the top of the ring buffer again. I'd need to do something similar on each read, and possibly add some logic over the read length / write free routines as well.

Is that how you'd approach this, or am I missing an easier way? I'm wondering if there will be some gotchas that I need to

Given these need to be done for each read/write/count operation, I'm wondering if this can be done efficiently in the library.

[MaJerle]

Can you provide ab exanple code that makes it problematic for you? I do not understand this my first block equation.

Thanks.

[Voidmenull]

Thank you for the new release, i just started a new project with it :)

[path321]

Hi MaJerie,

Maybe a bit out of scope as lwrb is a C library, but I had problem with using the library in a cubeIDE C++ project containing both C and C++ source code, as there was a conflict with .cpp files and <stdatomic.h>. Finally, following this post , modified lwrb.h as below :

• removed #include in line 52
• Added the following snippet at line 40

#if !defined(LWRB_DISABLE_ATOMIC) || __DOXYGEN__
#ifndef __cplusplus
#include <stdatomic.h>
#else
#include <atomic>
    typedef std::atomic<unsigned long> atomic_ulong;
#endif
#endif

Thank you for the amazing libraries, fast, clearly written and well documented as well

[MaJerle]

Be careful doing this. lwrb.c has been compiled as C while the rest of the app as non-C. You may have binary incompatibilities and therefore undefined behavior.

[path321]

Do you mean incompatibilities and undefined behaviour regarding how <stdatomic.h> and < atomic > each handle threads operation or with the proper functioning of the ring buffer ?

[MaJerle]

Technically yes. Structure representation may be different between C and C++. You initialize your lwrb_t strucuture in C project, while lwrb.c has been compiled as C file. Maybe replace lwrb.c to lwrb.cpp to compile it as C++.