You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 👍
(unless you need a stack :D)
The text was updated successfully, but these errors were encountered:
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 👍
(unless you need a stack :D)
The text was updated successfully, but these errors were encountered: