- 1
- 2
while(!ThreadActivateFlag)
Sleep(0);
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+162
while(!ThreadActivateFlag)
Sleep(0);
Срочно выручайте! Если не успеем, он свернёт горизонт и захавает мир!
Ч. Петзолд "Программирование для Windows® 95 в двух томах" Том 2 стр. 41
Так что Sleep(0) там нормально стоит, но светофор однозначно глючить будет.
Для "мелкодисперсной" синзхронизации с коротким временеим ожидания - именно spin-lock, как показано выше, и ни в коем случае не "ждать объекта".
"Ждать объекта" - это только для грубой синхронизации с длительными спячками. "Объектами" синхорнизируют GUI, IO и т.п. тяжеловесные вещи.
Вычисления же синхронизируются имено во таким spin-lock-ами. Это если вам нужна эффективность, конечно.
http://www.govnokod.ru/4937#comment58422
И недоучка - программист.
Приведенный код - простейшая классическая реализация spin-lock. Фукция `Sleep` с параметром `0` в WinAPI имеет особый смысл и особое назначение. `Spin(0)` означает "передать остаток временного слайса следующему готовому к выполнению потоку". Т.е. это сделано именно для того, чтобы не грузить процессор бессмысленным мотанием по пустому циклу, а вместо этого передать ненужный остаток временного слайса дальше, на полезную работу. Т.е. никакого потока-эгоиста тут нет. Все в точности наоборот: налицо корректно и умышленно примененый прием, делающий поток НЕ эгоистом.
Spin-lock - исключительно полезный синхронизационный примитив. Придираться в данном случае можно было бы к оформлению: вместо выделенного примитива, реализация spin-lock протя вписана явно в код - это криво. Отдельно стоило бы рассмотреть традиционный вопрос применения spin lock вместо системного sleep-lock, но об этом без контекста говорить не приходится.
Все объяснил ниже в http://www.govnokod.ru/4937#comment58917
Отдельно стоит заметить, что, например, виндушный CRITICAL_SECTION - это внутеренне ни что иное, как гибрид spin-lock (вот именно такого, как приведено выше) и "ожидания события" (там семафор внутри, на самом деле). Сначала делается ожилание по spin-lock, и только потом, если дождаться не удалось, делается постановка на "ожидание события". Именно из-за грамотного использования spin-lock можно достичь существенно лучшей производительности CRITICAL_SECTION по сравнению с mutex.
>CRITICAL_SECTION
>mutex
ребятки, не хотел вас расстраивать, но 70е кончились.
для асинхронности без заморочек само собой CPS и корутины - stackless python, twisted, go..
А в реальной жизни у нас есть то, что в советском вузе называлось "семантическим разрывом между архитектурой ЭВМ и абстрактными языками программирования". И все эти эрланги-шмерланги в конечном итоге посторены вот на таких же спин-локах (больше попросту не на чем строить). А STM - это хорошо... Вот бы если бы оно еще в реальности приемлемо работало... (все из-за того же семантического разрыва).
Пока в машинных архитектурах царят 70-е, эти 70-е в программировании не закончатся. А всякие эрланги-шмерланги по этой причине годны только для написания разных "хелловорлдов" и т.п...
хотя к императиво..м нужно как к детишкам, измазавшимся говн... нет, просто промолчу.
Нет никакого sleep. Смысл спинлока в том, что-бы не отдавать управление другому потоку на многоядерных системах, тк это медленно. А Sleep как раз отдаёт управление другому потоку. В данном случае цикл быть спинлоком не может, раз отдаёт управление другому потоку.
http://ru.wikipedia.org/wiki/Spinlock
, тк отдаёт управление другому потоку в каждой итерации.
Более того, этот код работает медленее и пожирает значительно больше процессорного времени, чем код на событиях или код на спинлоках+событиях.
Спинлок обычно применяется именно совместно с событиями. Притом спинлок применяется только на многопроцессорных машинах. Сначало пытаемся ждать по спинлоку, но если не дождались за короткий период времени, то уже возвращаем управление другим потокам, что-бы зря не занимать процессор.
Если да, то гавнокод :)
Если есть другие потоки, которые манипулируют с этой переменной, то такое возможно при работе с аппаратурой. К примеру: прослушка порта и получение данных с датчиков, счетчиков и т.д. в очень короткие интервалы времени и на загрузку процессора вообще насрать, если хоть один бит мимо пройдет.