Исходное сообщение
"Рассматривается возможность перевода NTPsec на язык Rust или..." Отправлено Ordu, 10-Янв-17 11:15
Любой сборщик мусора периодически останавливает потоки выполнения, просто потому, что нет другого способа пересчитать объекты, ссылки на которые лежат в регистрах и на стеке. Другое дело, что некоторые алгоритмы, на самом деле даже большинство алгоритмов, стремятся свести такие остановки к минимуму. Например, выполнить максимум работы в бекграунде, из параллельного потока. Помечать области памяти, с которыми идёт работа, флагом ro, с тем чтобы проводить все манипуляции несмотря на то, что программа продолжает работать с объектами -- и это проходит гладко, если программа ничего не меняет, но в случае, если она вносит изменения, процессор выкидывает исключение, выполнение задачи прерывается, сборщик мусора обрабатывает исключение и позволяет программе продолжать выполнение. Там есть разные техники преодоления этих проблем, между прочим очень любопытные -- я читал книжку об этом запоем, кстати очень рекомендую в качестве увлекательного чтения какое-нибудь систематическое описание этих алгоритмов. Но финально всё сводится к тому, что останавливаются _все_ потоки, сборщик мусора из каждого потока выковыривает содержимое регистров и стековых фреймов, быстренько составляет список объектов достижимых при помощи регистров и стека, после чего позволяет программе продолжать работу, а сам заканчивает итерацию сборки мусора. В самых продвинутых алгоритмах, этот этап остановки очень короткий и неплохо масштабируется, потому что остановив все потоки на всех процессах, сборщик мусора сам начинает работать многопоточно, задействуя все процессоры, для того чтобы быстро-быстро всё сделать. Но как бы там ни было, остановки, пускай и короткие, происходят, причём чем круче алгоритм, тем менее предсказуемо когда произойдёт остановка. Любая запись в память может привести к прерыванию и переключениям между ring3 и ring0. Периодически же будут возникать остановки типа stop-the-world. Это может быть неважно для десктопного приложения, но для синхронизации времени, где речь идёт о микросекундах -- это не вариант. Точнее не так: это может быть допустимо, и Раймонд говорит о том, что может быть "и так проканает", если паузы действительно будут измерятся небольшим числом микросекунд, как обещают go-фаги. Но может быть и не проканает.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Любой сборщик мусора периодически останавливает потоки выполнения, просто потому, что > нет другого способа пересчитать объекты, ссылки на которые лежат в регистрах > и на стеке. Другое дело, что некоторые алгоритмы, на самом деле > даже большинство алгоритмов, стремятся свести такие остановки к минимуму. Например, выполнить > максимум работы в бекграунде, из параллельного потока. Помечать области памяти, с > которыми идёт работа, флагом ro, с тем чтобы проводить все манипуляции > несмотря на то, что программа продолжает работать с объектами -- и > это проходит гладко, если программа ничего не меняет, но в случае, > если она вносит изменения, процессор выкидывает исключение, выполнение задачи прерывается, > сборщик мусора обрабатывает исключение и позволяет программе продолжать выполнение. Там > есть разные техники преодоления этих проблем, между прочим очень любопытные -- > я читал книжку об этом запоем, кстати очень рекомендую в качестве > увлекательного чтения какое-нибудь систематическое описание этих алгоритмов. Но финально > всё сводится к тому, что останавливаются _все_ потоки, сборщик мусора из > каждого потока выковыривает содержимое регистров и стековых фреймов, быстренько составляет > список объектов достижимых при помощи регистров и стека, после чего позволяет > программе продолжать работу, а сам заканчивает итерацию сборки мусора. В самых > продвинутых алгоритмах, этот этап остановки очень короткий и неплохо масштабируется, потому > что остановив все потоки на всех процессах, сборщик мусора сам начинает > работать многопоточно, задействуя все процессоры, для того чтобы быстро-быстро всё сделать. > Но как бы там ни было, остановки, пускай и короткие, происходят, причём > чем круче алгоритм, тем менее предсказуемо когда произойдёт остановка. Любая запись > в память может привести к прерыванию и переключениям между ring3 и > ring0. Периодически же будут возникать остановки типа stop-the-world. Это может быть > неважно для десктопного приложения, но для синхронизации времени, где речь идёт > о микросекундах -- это не вариант. Точнее не так: это может > быть допустимо, и Раймонд говорит о том, что может быть "и > так проканает", если паузы действительно будут измерятся небольшим числом микросекунд, > как обещают go-фаги. Но может быть и не проканает.
	Введите код, изображенный на картинке: