Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Не сгущайте красок. При любой многозадачности мьютексы прекрасно работают до определенного уровня загрузки, и лишь после нее начинается лавинообразный рост коллизий.

В кооперативной однопроцессорной (одноядреной) многозадачности ожидающий на мьютексе поток освободит ресурс, что позволит с большой вероятностью отдать (рано или поздно) процессор обратно потоку, который захватил мьютекс. А при правильном написании кода, т.е. если не будет ожидающих сигналов/хендлов операций в промежутках между захватом и отпусканием, то поток, захвативший мьютекс, никогда не будет неожиданно вытеснен. С коллизиями столкнулись именно при насильном вытеснении потоков и именно в защищённом режиме, бо в плоском режиме переключение потоков было достаточно дешевым.


ЕМ>Это ж, по сути, классическая система массового обслуживания

Которые, по-классике, пишутся не на мьютексах, а на семафорах и атомарных (lock-free в мультипроцессорной конфигурации) операциях.

Мьютексы — это дешевый механизм обеспечения сериализации доступа к ресурсу для случая, когда "облом подумать". ))


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

Разумеется.
Стоимости промаха TLB в инете есть — можно оценивать.

Но лучше всего гонять конкретные сценарии в тестах в различных техниках исполнения, конечно.


ЕМ>Если все остальное уже оптимизировано, и на первое место вылезли затраты на переключение — значит, их действительно пора оптимизировать.

Угу. Например, мы обслуживаем скоростную диспетчеризацию из сотен/тысяч источников.
Тут переключения контекстов могут отожрать до 95% всех тиков, если каждый источник обрабатывается отдельным потоком ОС.


ЕМ>Но, если мы сейчас прикинем вес затрат на переключение на фоне веса затрат, создаваемых типичным современным софтом, нам потребуется неслабый микроскоп, чтоб их разглядеть.

Если мы говорим об эффективности и реалтайме, то обычно и платформы используются соответствующие.
С/С++ или тот же дотнет в специальном "оптимизированном" режиме написания кода, чтобы не дёргать GC на каждый чих и вообще с уменьшенной суммарной косвенностью графа объектов.


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

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


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

Ну-ну-ну... ))
Этот "софт общего назначения", для случая мультимедиа, построит граф узлов в каком-нить DirectShow или прочих OpenAL и скажет этому графу ему "старт!"
А далее будет работать охрененно вылизанные подкапотные вещи использованной либы — кодеки/фильтры, источники и приёмники сигналов и т.д.

Т.е., задача прикладного кода сводится лишь к построениях графа из готовых кубиков и конфигурированию его.
Но мы-то обсуждаем "кишки". ))


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

Я имею в виду классическое определение, ес-но.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Не сгущайте красок. При любой многозадачности мьютексы прекрасно работают до определенного уровня загрузки, и лишь после нее начинается лавинообразный рост коллизий.

В кооперативной однопроцессорной (одноядреной) многозадачности ожидающий на мьютексе поток освободит ресурс, что позволит с большой вероятностью отдать (рано или поздно) процессор обратно потоку, который захватил мьютекс. А при правильном написании кода, т.е. если не будет ожидающих сигналов/хендлов операций в промежутках между захватом и отпусканием, то поток, захвативший мьютекс, никогда не будет неожиданно вытеснен. С коллизиями столкнулись именно при насильном вытеснении потоков и именно в защищённом режиме, бо в плоском режиме переключение потоков было достаточно дешевым.


ЕМ>Это ж, по сути, классическая система массового обслуживания

Которые, по-классике, пишутся не на мьютексах, а на семафорах и атомарных (lock-free в мультипроцессорной конфигурации) операциях.

Мьютексы — это дешевый механизм обеспечения сериализации доступа к ресурсу для случая, когда "облом подумать". ))


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

Разумеется.
Стоимости промаха TLB в инете есть — можно оценивать.

Но лучше всего гонять конкретные сценарии в тестах в различных техниках исполнения, конечно.


ЕМ>Если все остальное уже оптимизировано, и на первое место вылезли затраты на переключение — значит, их действительно пора оптимизировать.

Угу. Например, мы обслуживаем скоростную диспетчеризацию из сотен/тысяч источников.
Тут переключения контекстов могут отожрать до 95% всех тиков, если каждый источник обрабатывается отдельным потоком ОС.


ЕМ>Но, если мы сейчас прикинем вес затрат на переключение на фоне веса затрат, создаваемых типичным современным софтом, нам потребуется неслабый микроскоп, чтоб их разглядеть.

Если мы говорим об эффективности и реалтайме, то обычно и платформы используются соответствующие.
С/С++ или тот же дотнет в специальном "оптимизированном" режиме написания кода, чтобы не дёргать GC на каждый чих и вообще с уменьшенной суммарной косвенностью графа объектов.


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

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


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

Ну-ну-ну... ))
Этот "софт общего назначения", для случая мультимедиа, построит граф узлов в каком-нить DirectShow или прочих OpenAL и скажет этому графу "старт!"
А далее будет работать охрененно вылизанные подкапотные вещи использованной либы — кодеки/фильтры, источники и приёмники сигналов и т.д.

Т.е., задача прикладного кода сводится лишь к построениях графа из готовых кубиков и конфигурированию его.
Но мы-то обсуждаем "кишки". ))


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

Я имею в виду классическое определение, ес-но.