История изменений

Я бы сказал не в общем случае, а вообще такого не должно быть, чтобы item == head до присваивания. Ведь голова списка по определению указывает на такой элемент, который в списке есть. А именно последующий CAS является добавлением элемента в список, до этого элемент списку не принадлежит. И assert(item != head) вызывает падение программы лишь при условии, что item == head. То есть возникает невозможная ситуация, которая возможна лишь при разрушении списка.

Спин блокировка - вид сбоку.

Не совсем. Вот смотри. В той же ChibiOS/RT после каждого прерывания запускается перепланирование задач, если что-то изменилось. У меня перепланирование (переход на следующую итерацию цикла while вместо выхода из него) происходит только если случилось прерывание во время планирования. То есть просто к стоимости каждого прерывания добавляется стоимость новой итерации цикла. С учётом того, что цикл маленький, эта добавленная стоимость будет очень мала. То же касается и функций добавления/удаления. К стоимости прерывания добавляется стоимость перезапуска всех функций добавления/удаления, а также планировщика, которые он прервал.

И все эти циклы гарантированно завершаться как только перестанут приходить прерывания. Однако если прерывания приходят так часто, что даже коротенькие функции не успевают дойти до конца, то система явно перегруженна, а в таких условиях никакая RTOS ничего не гарантирует (кроме того, что высокоприоритетные прерывания, не использующие функции RTOS, будут нормально работать, но у меня тоже так).

Я бы сказал не в общем случае, а вообще такого не должно быть, чтобы item == head до присваивания. Ведь голова списка по определению указывает на такой элемент, который в списке есть. А именно последующий CAS является добавлением элемента в список, до этого элемент списку не принадлежит. И assert(item != head) вызывает падение программы лишь при условии, что item == head. То есть возникает невозможная ситуация, которая возможна лишь при разрушении списка.

Спин блокировка - вид сбоку.

Не совсем. Вот смотри. В той же ChibiOS/RT после каждого прерывания запускается перепланирование задач, если что-то изменилось. У меня перепланирование (переход на следующую итерацию цикла while вместо выхода из него) происходит только если случилось прерывание во время планирования. То есть просто к стоимости каждого прерывания добавляется стоимость новой итерации цикла. С учётом того, что цикл маленький, эта добавленная стоимость будет очень мала. То же касается и функций добавления/удаления. К стоимости прерывания добавляется стоимость перезапуска всех функций добавления/удаления, а также планировщика, которые он прервал.

И все эти циклы гарантированно завершаться как только перестанут приходить прерывания. Однако если прерывания приходят так часто, что даже коротенькие функции не успевают дойти до конца, то система явно перегруженна, а в таких условиях никакая RTOS ничего не гарантирует (кроме того, что высокоприоритетные прерывания, не использующие функции RTOS, будут нормально работать).