I actually think this is important.
The meaning of "lockless" becomes quite clear when both relayfs logging
schemes are compared. In the locking scheme, one of the following must
[They "must" be used because the relay_write() function could be called
from within an interrupt handler and the only safe way to manipulate
buffers that are accessible in read-write both to interrupt handlers
and other code is to disable interrupts in one way or another.]
Both of these disable interrupts on the local processor (actually,
spin_lock_irqsave() has a local_irq_save() inside it.)
With the cmpxchg, there is no interrupt disabling whatsoever. The code tries
to allocate some space, and retries if it fails. The most likely reason
it may fail is in the case when an interrupt occurs and that interrupt's
handler tries and succeeds in allocating space in the buffer instead of
the interrupted code. To the best of my memory, the tests we've done show
that the code very rarely has to try more than two or three times.
While the code does the loop once or twice, however, the processor is
free to continue handling interrupts. None of the code instances is
actively spining in waiting for another instance to relinquish a lock.
There is, indeed, no lock here to be acquired or to be waited on.
Embedded and Real-Time Linux Expert
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/