* Mathieu Desnoyers ([email protected]) wrote:
[...]
> One more thing: I think we need to add cmm_smp_read_barrier_depends()
> before returning the node pointers in dequeue, first, and next
> operations. This memory barrier would match the implicit barrier in the
> enqueue ordering write to the prior tail's next pointer with writes to
> the node content that would have been performed beforehand by the
> caller.
Please note that the only reason why I propose to use
"cmm_smp_read_barrier_depends()" before returning nodes in dequeue,
first, and next functions rather than a full cmm_smp_mb() is because I
fail to see a case where an architecture would reorder a dependent store
before the load of the pointer.
I very well imagine a use-case where we have node N within the structure
X like the scenario below, where we write to X immediately after dequeue:
CPU 0 CPU 1
store X content
(implicit full memory barrier
implied before uatomic_xchg)
enqueue X->N
dequeue X->N
(which barrier here ?)
write to X immediately.
If we assume that no reordering of a store that depends on loading a
pointer can arrive, then I think we should be good with only a
read_barrier_depends() on CPU 1. Otherwise, we might want to put a full
barrier there to ensure that we don't race with CPU 0 storing content to
X.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
