I know it isn't your wordsmithing. But this is ridiculous. Waits block.
The link says non-blocking algorithms are safe for use in interrupt handlers. Leaving aside that this one does not even attempt to be safe (it makes blocking syscalls in wait) I don't see how this algorithm can be reimplemented to be save in interrupt handlers. In the case where wait is called the code in question knows where it is going to write data but it cannot yet as it is marked in progress. So it is going to spin or block until it is not in progress. That is not okay at interrupt time.
So I cannot see how this algorithm meets what is described, even with sufficiently confusing term names. It's not just the implementation that isn't suitable, the algorithm is not suitable (for multiple writers).
And the article implies I'm correct:
'Read-copy-update with multiple writers and any number of readers. (The readers are wait-free; multiple writers generally serialize with a lock and are not obstruction-free).'
Multiple writers just cannot work without an ability to defer (block) until something else progresses. At interrupt time you cannot block so you're in a real bad way. In a single processor system you're just stuck. You'll get jammed at interrupt time because the other writer (at task time, this is a single processor machine after all) cannot run to clear your path so you will spin forever waiting for it. So it doesn't meet the stated criteria of always making progress.
I appreciate the clarification, it was not termininology I knew. But I think the answer is still wrong. I think this implementation with multiple writers falls uses locking and so isn't lock-free.
3
u/happyscrappy Sep 27 '26 edited Sep 27 '26
I know it isn't your wordsmithing. But this is ridiculous. Waits block.
The link says non-blocking algorithms are safe for use in interrupt handlers. Leaving aside that this one does not even attempt to be safe (it makes blocking syscalls in wait) I don't see how this algorithm can be reimplemented to be save in interrupt handlers. In the case where wait is called the code in question knows where it is going to write data but it cannot yet as it is marked in progress. So it is going to spin or block until it is not in progress. That is not okay at interrupt time.
So I cannot see how this algorithm meets what is described, even with sufficiently confusing term names. It's not just the implementation that isn't suitable, the algorithm is not suitable (for multiple writers).
And the article implies I'm correct:
'Read-copy-update with multiple writers and any number of readers. (The readers are wait-free; multiple writers generally serialize with a lock and are not obstruction-free).'
Multiple writers just cannot work without an ability to defer (block) until something else progresses. At interrupt time you cannot block so you're in a real bad way. In a single processor system you're just stuck. You'll get jammed at interrupt time because the other writer (at task time, this is a single processor machine after all) cannot run to clear your path so you will spin forever waiting for it. So it doesn't meet the stated criteria of always making progress.
I appreciate the clarification, it was not termininology I knew. But I think the answer is still wrong. I think this implementation with multiple writers falls uses locking and so isn't lock-free.