-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Queue not thread/interrupt safe? #355
Labels
Comments
Hi, it's not possible to have 2 What can happen is that there is a windows on inconsistency in which the queue can be considered empty/full while there is 1 element in it or 1 less than full - and this is by design. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am developing in RISC-V and in my understanding the Queue is not thread or interrupt safe. Imagine the following scenario where an item is dequeued:
Imagine if the
inner_dequeue
function is interrupted at position(1)
, right between the load of thehead
and thetail
and in the other context (either interrupt or different thread)inner_dequeue
is executed. Now the head still is already incremented by the second context, but the original context still uses the old value. Like this, one value is returned/dequeued twice.As far as I understand, the atomics do not prevent this behavior. Or at least not for the single core
risv32imc
target. Here, interrupts get disabled and re-enabled just for the two load instructions. But they are enabled in between the two loads:So I am not sure if thread/interrupt safety is guaranteed, but if it is, I would suggest using a critical section around the whole dequeue process.
The text was updated successfully, but these errors were encountered: