Здравствуйте, vdimas, Вы писали:

V>В кооперативной-однопроцессорной (одноядерной) многозадачности оно таким злом не было за невозможностью.
V>Вот там мьютексы были паиньками, что ими всё засрали нахрен в 80-е до 95-го, а потом как ужаснулись, когда пошло более одного ядра + вытесняющая многозадачность...

Не сгущайте красок. При любой многозадачности мьютексы прекрасно работают до определенного уровня загрузки, и лишь после нее начинается лавинообразный рост коллизий. Это ж, по сути, классическая система массового обслуживания — турникет, дорога, транспорт, телефонная сеть и прочее, она требует прежде всего оптимизации по ресурсам. Менять алгоритмы требуется лишь при специфических требованиях, вроде hard realtime. Soft realtime с любым разумным средним временем отклика достигается масштабированием.

V>переключение потока дорогое еще для потока, который вытесняют
V>Который поток ставят — его дорого ставить

Все эти оценки "дорого-дешево" имеют смысл только в отношении удельного веса в общей совокупности затрат. Если все остальное уже оптимизировано, и на первое место вылезли затраты на переключение — значит, их действительно пора оптимизировать. Но, если мы сейчас прикинем вес затрат на переключение на фоне веса затрат, создаваемых типичным современным софтом, нам потребуется неслабый микроскоп, чтоб их разглядеть.

Так что об этих затратах уместно говорить в контексте какой-нибудь специализированной промышленной системы, софт под которую или писан с нуля квалифицированными кадрами, или ими же переделан из софта общего назначения. Если же взять навскидку произвольную систему общего назначения, от которой ожидается realtime в плане той же мультимедии, то затраты на переходы в режим ядра, переключение контекста и подобное — одни из последних кандидатов на оптимизацию.

V>Т.е., lock-free гарантирует, что в каждый момент времени хотя бы один поток продвигается в своём исполнении.

Да, но только если это lock-free одновременно и для потоков, и для их общих ресурсов.