On Fri, 11 Oct 2019, Manfred Spraul wrote:
But you are right, there are two different scenarios:
1) thread already in another wake_q, wakeup happens immediately after
the cmpxchg_relaxed().
This scenario is safe, due to the smp_mb__before_atomic() in wake_q_add()
2) thread woken up but e.g.
On 10/11/19 6:55 PM, Davidlohr Bueso wrote:
On Fri, 11 Oct 2019, Manfred Spraul wrote:
Update and document memory barriers for mqueue.c:
- ewp->state is read without any locks, thus READ_ONCE is required.
In general we relied on the barrier for not needing READ/WRITE_ONCE,
but I agree this sc
On Fri, 11 Oct 2019, Manfred Spraul wrote:
Update and document memory barriers for mqueue.c:
- ewp->state is read without any locks, thus READ_ONCE is required.
In general we relied on the barrier for not needing READ/WRITE_ONCE,
but I agree this scenario should be better documented with them.
Update and document memory barriers for mqueue.c:
- ewp->state is read without any locks, thus READ_ONCE is required.
- add smp_aquire__after_ctrl_dep() after the RAED_ONCE, we need
acquire semantics if the value is STATE_READY.
- document that the code relies on the barrier inside wake_q_add()
4 matches
Mail list logo
