Для чего нужен Timer hack thread в майнкрафте?

Объяснение из гугла. Я, правда, нифига не понял, но может тебе будет полезно.

Начать, наверное, стоит с того, как работает Thread.sleep. Основная задача такого метода - поставить поток на «паузу», на некоторое время. Обычно, в момент вызова такого метода, JVM обращается к операционной системе, а именно, к такой штуке как thread scheduler. Как может быть понятно из названия, он заведует подобными манипуляциями с потоками. Но, для JVM так же важно вовремя пробудить поток, так как изначально в методе sleep был указан интервал. Что бы иметь такую возможность, JVM не всегда использует методы самой операционной системы. Так, JVM от Sun(Компания, которая разрабатывала Java до Oracle, думаю знаете), отправляла поток в специальный пул, который с некоторой периодичностью опрашивался на предмет пробуждения. Такой себе ивент. И, обычно, у каждой ОС был свой такой период вызова ивента. Для Linux - 1ms, для Windows - 10-15ms. Ну, и всё хорошо себе работало. До момента, когда в 2001 году(Это была Java 3) был обнаружен баг: Если выставлять в Thread.sleep слишком маленький интервал, системные часы Windows станут идти быстрее! Круто, да?) Ну, баг пофиксили, методом перехвата установки интервала с ОС, на JVM, теперь она контролировала это дело и всегда устанавливала 1ms. И что бы вы думали? В 2006 году оказывается, что при фиксе первого бага, был допущен ещё один баг, в связи с которым, интервал практически никогда так и не устанавливался на 1мс. Случилось так потому, что код фикса был написан не в том dll и не учитывал некоторый интервал при работе с терминалом. Но, за всё это время(около 5 лет), разработчики не получили ни одного репорта, поэтому решили, что лучше не трогать, раз уж так работает. Но что делать, если кто-то разрабатывал программу(Судя по тому треду, Майнкрафт был одним из таких программ), которой очень важно было, что бы её потоки пробуждались строго в указанное время? К счастью, этот интервал можно было установить самому, с помощью некоторого хака. Более того, такой интервал можно было установить не per-thread, а per-program! В общем, как вы уже догадались, этим хаком и был код выше, суть которого была в том, что бы с помощью создания демона, который вечно спит, минимизировать этот самый интервал пробуждения. Таким образом, была достигнута максимальная точность, где требовались какие-либо операции со временем.

Сейм щит, довольно бессвязный набор фактов. Зато хотя бы появилось подтверждение того, что это костыль, упирающийся в планировщик.

А так было непонятно чтоле? Само название потока про это говорит.

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

Это если я правильно помню костыль для таймера windows. Дефолтный интервал там что-то вроде 10ms, а такими приседаниями можно поднять до 1ms. Как эот конкретно работает уже никто не помнит, но вроде как раз соль в вызове sleep с большим интервалом.

Вообще история с таймером windows давняя, обычно советуют включить Windows Media Player который автоматически вызывает поднятие разрешения таймера. И метод в WinAPI есть. Но поскольку майн на жабе, то чтобы не тащить dll с вызовом одного метода, сделали так (видимо в jvm торчит вызов увеличения разрешения таймера при вызове sleep с большим значением).

Майн - вещь со слабо развитой многопоточностью для такого размера софтины, разных потоков в нём всего штук 10

думаете лучше выбросить event-loop и сделать по потоку на юзверя? ;)

Не использовать многопоточность в мире, где 32 аппаратных потока уже у консьюмерских процессоров это точно глупо. А какую модель I/O использовать это вообще другой вопрос.

Платформонезависимость так платформонезависима. Я начинаю понемногу понимать, почему жава проиграла шарпу десктоп — потому что кодеры сана не дружили с виндой, хотя она являлась №1 десктопной платформой на тот момент.

Но поскольку майн на жабе, то чтобы не тащить dll с вызовом одного метода, сделали так (видимо в jvm торчит вызов увеличения разрешения таймера при вызове sleep с большим значением).

NtSetTimerResolution лежит в ntdll.dll, которую загружают абсолютно все win32 приложения.

Не использовать многопоточность в мире, где 32 аппаратных потока уже у консьюмерских процессоров это точно глупо

Как показывает практика, малое число кодеров способны работать с кучей потоков и сохранять хорошую отзывчивость. Порой руки настолько кривые, что даже с быстрым системным таймером отклик получается 500+ мс. Не помню, где такой прикол был, по-моему Watch dogs 2 на гипертредовом интеле.

А фундаментальная причина лежит в плохой поддержке многопоточности на уровне современных популярных ОС. Очень долгое время был однопоток на десктопе и многопоток на сервере с независимыми задачами, но не было многопотока в тесно связанной системе. Самое смешное то, что винда является одним из лидеров в этом направлении, поскольку, например, с семерки получила планировщик в режиме пользователя
https://docs.microsoft.com/en-us/windows/win32/procthread/user-mode-scheduling
функциональный аналог которого уже написан для линукса, но до сих пор так и не принят в ядро. И поскольку винда потоки с высвобожденным мутексом ставит вперед планировщика. Поскольку в ней есть RPC в ядре, который так и не могут придумать на никсах вместо D-Bus с четырьмя переключениеми контекста на вызов в одну сторону.

Да, в линукс добавили в 2.6 родные потоки и футексы, но, блин, 2004 год, а до тех пор это были процессы с общей памятью, пайпы для синхронизации, и прочие костыльные радости. Ну и самая главная проблема всех юниксов — это наличие форка. Пока в систему не добавят гарантию защиты от форка, написание многопотоков будет сплошным костылестроением. Sun один из первых это осознал и добавил в Solaris posix_spawn, который запускает процесс без форка. Я вот сейчас свою либу пишу, и с ужасом подумываю о том, что произойдет, если какой-то поехавший решит использовать ее совместно с форком из питонового multiprocessing.

оценивать уровень многопоточности просто подсчётом потоков это пушка

висит в вечном ожидании

тебя ждёт ещё множество открытий

Расскажи подробней, в чём проблема форка и чем солярный spawn лучше. Или ссылок на чтиво подкинь.

Расскажи подробней, в чём проблема форка и чем солярный spawn лучше. Или ссылок на чтиво подкинь

https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf

Форк создает копию одного потока, но у тебя ведь может быть много потоков. Проблемы не было, пока в никсах не было потоков. А таки в линуксе не было потоков до 2.6.

https://docs.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeg...

Проблема в том, что майн это ещё и конечный автомат. А потоки не очень способствуют работе конечных автоматов.

Далёкие межчанковые взаимодействия довольно редки, с ходу могу вспомнить только хил дракона края о кристаллы. Не вижу особой сложности в том, чтобы вынести подобные вещи в посттик, а обсчёт чанков раскидать по потокам так, чтобы не пересекались во времени. Однако ж, по какой-то причине мы имеем что имеем..

Далёкие межчанковые взаимодействия довольно редки

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

ИМХО, это баг телепортации яйца, вызванный отсутствием автоматической прогрузки запрошенного чанка. Куча дюпов была и есть, связанных с выгрузкой чанка с контейнером, интерфейс которого открыт у игрока. Примерно в 100% случаев баг «фиксится» принудительным закрытием gui на клиенте при удалении от открытого блока, чему несказанно рады читеры.

Ага, да, осталось только ещё где-то jni врапеер для этого взять, поскольку в жабе его нет.