as I understand your ring buffer is targeted for embedded systems, which is exactly what I am using it for.
I think it can be even more generalized, by adding a template option to omit any synchronization and atomicity guarantees for the case that the ringbuffer is not shared between user and interrupt context.
The impact on the generated instructions might be negligible currently, but if PR #9 were implemented, it would make a difference as one would not have to use locks / disable interrupts.
If this ring buffer would provide both an atomic and a non-atomic version, one could truly use it for all usecases :+1:
(unless you need a stack :D)
There is fake_tso parameter that makes all atomic accesses relaxed. I don't think that separate non atomic codebase would yield measurable speed/size benefits.
Hi,
as I understand your ring buffer is targeted for embedded systems, which is exactly what I am using it for.
I think it can be even more generalized, by adding a template option to omit any synchronization and atomicity guarantees for the case that the ringbuffer is not shared between user and interrupt context.
The impact on the generated instructions might be negligible currently, but if PR #9 were implemented, it would make a difference as one would not have to use locks / disable interrupts.
If this ring buffer would provide both an atomic and a non-atomic version, one could truly use it for all usecases :+1:
(unless you need a stack :D)