Fundemental problem is parisc only supports one atomic operation
(LDCW/LDCD) and uses spinlocks for all atomic operations including
xchg/cmpxchg.
Using spinlocks for the implementation of xchg on SMP might be
problematic.
If you implement things like this, several subtle things might
break. For example, there is code in a few spots (or, at least at one
time there was) which assumed the update of the datum itself is atomic
and uses this assumption to do lock-free read-only accesses of the
data.
If you require an external agent (f.e. your spinlock) because you
cannot implement xchg with a real atomic sequence, this breaks the
above assumptions.
It is very common to do things like:
producer(elem)
{
elem->next = list->head;
xchg(&list->head, elem);
}
consumer()
{
local_list = xchg(&list->head, NULL);
for_each(elem, local_list)
do_something(elem);
}
In fact we had code excatly like this in the buffer cache at one
point in time.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/