Ну какой смысл в разблокировании ? Пусть себе висит и

ждет завершение операции с любым исходом..
Разблокирование таким образом как правило требуется при останове сервера , когда нужно как можно быстрее завершить блокирующие трансп. операции, освободить ресурсы и закруглиться по хозяйству

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

Вы что-то делаете неправильно. Проверить наличие данных в сокете ничего не стоит и занимает 0 мс. Можно поспать до следующей проверки 0 мс, и у процессора будет 0% нагрузки.

Вы предлагаете проверять сокет через каждые 0мс и при этом не будет никакой нагрузки?

Да, именно так. Достаточно просто спросить у сокета, есть ли входящие данные, это делается командой select

Если проверять каждые 0 мс я загружу одно ядро процессора на 100%. Так не пойдёт.

Цикл со sleep(0) и select() не сложно проверить.

Зачем? Не вижу в этом смысла. Либо бы ждем на сокете либо грузим проц, третьего варианта не будет.

Ваш вариант чтения с ожиданием грузит проц. Вы решили, что мой вариант будет работать точно так же? =) Впрочем, если вы так уверены в результате без эксперимента, то вам помощь не нужна.

А зачем в вашем цикле Sleep(0)? Он какую роль играет?

Контекст переключает. Если в слип передать 0, он оставшуюся часть интервала своего отдает другому потоку с таким же приоритетом

Но если есть незанятые ядра процессора, то sleep(0) тупо вернет управление обратно, т.е. контекст даже не переключится.

Sleep в любом случае вызовет ZwDelayExecution который произведет отдачу неиспользуемого кванта нити

Стикер

Это может быть. Но это не обязательно будет переключение контекста. Просто отсчет кванта начнётся заново.

Это что-то новое, где ты такое вычитал? :))))

Для процессора это не разгрузка. С какой стати?

Сделай тест из 10000 вызовов sleep(0) в цикле и замерь в микросекундах. Операция переключения контекста сильно повлияет на общее время.

Ты кажется не понимаешь как это работает в общем и делаешь не верные выводы :) Для начала начни с вот этого, там про KWAIT_REASON и про прочее https://wasm.in/blogs/planirovschik-potoki-i-processy.517/

Стикер

Я как раз в общем понимаю как это работает. Но не разбирался с каждой деталью. Ты видимо ориентируешься в деталях. Это очень круто.

Выяснили кстати чего у Акшенов в DT Enabled слетает. Там не заглушен апдейт в дизайнтайме, а т.к. в дизайнтайме у акшенов нет отработчиков они и дисейблятся. Причем самое интересное что это только с MainMenu так глючит.

Сделал тест с циклом из 10000 вызовов. Общее время составило 1.8 миллисекунд. Это совершенно не похоже на переключение контекста. Если бы оно реально было, то время было бы никак не меньше 10 миллисекунд, а скорее 100 миллисекунд. Тут не нужно детально вникать в реализацию каждой функции, достаточно сделать простейший тест и все на свои места встанет.