These were always no-op on TSO. For non-TSO, we assume
data dependent ordering. Next to data does not require ordering
but data to next does. However, a re-ordering here is benign
in that a stale load will observe an initialized NULL value.
We would rather not pay the load cost for the common case.
Write-side fences are unchanged.
From discussions with markj@freebsd.org.
These new macros are very convenient for modifying a SLIST after
using CK_SLIST_FOREACH_PREVPTR to find an element to remove
or a position to insert.
FreeBSD sys/queue.h already has SLIST_REMOVE_PREVPTR.
I would like to use the new macros in a change that I am planning
for FreeBSD kernel:
https://reviews.freebsd.org/D16016https://reviews.freebsd.org/D15905
CK_LIST_INSERT_HEAD was incorrectly managing prev
pointer on insertion to non-empty list. This bug
would cause erroneous behavior on CK_LIST_REMOVE
to non-head elements. Unit test will be updated
for this regression.
This operation is of format:
CK_S*LIST_MOVE(a, b, linkage) and is equivalent to intializing
a with the contents of b. This is done in a manner that is atomic
with respect to readers. Read-only operations are still valid in
b, but behavior is undefined for write-side operations on b after
a MOVE operation.
Writer-side synchronization is still necessary. My current use-cases call for
SLIST and LIST implementations, and as such, I've only implemented support
for these. TAILQ facilities will be developed when the time comes that I require
them or if there is sufficient user-demand.
Samy Al Bahra
Andriy Gapon
Matt Macy
Aidan Cully
Roman Lebedev
Samy Al Bahra
Samy Al Bahra
Abel Mathew