Java Thread.suspend точной семантики

Question

Этот вопрос НЕ об альтернативах Thread.suspend. Речь идет о возможности реализовать блокировку смещения с помощью Thread.suspend, которую (я считаю) нельзя реализовать с помощью Thread.interrupt или аналогичных альтернатив.

Я знаю, что Thread.suspend устарел.

Но я хочу знать точную семантику Thread.suspend.

Если я вызываю thread1.suspend(), гарантированно ли я буду заблокирован до полной остановки thread1? Если я вызываю thread1.resume(), может ли этот вызов быть видимым для других потоков не по порядку?

Более того, если я успешно приостановлю поток, будет ли этот поток приостановлен в некоторой безопасной точке? Смогу ли я увидеть его промежуточное состояние (поскольку Java запрещает из чистого значения даже в не правильно синхронизированной программе, я не верю, что это разрешено) или вижу что-то не в порядке (если suspend - это асинхронный запрос, тогда я обязательно увижу такого рода вещи)?

Я хочу знать это, потому что я хочу реализовать некоторую игрушечную асимметричную блокировку в Java (например, BiasedLock в HotSpot). Используя Thread.suspend, вы можете реализовать Dekker-подобный замок без барьера загрузки магазина (и перенести нагрузку на редкий путь). Мои эксперименты показывают, что это работает, но поскольку Thread.sleep достаточно для ожидания удаленного переключения контекста, я не уверен, что это гарантированное поведение.

Кстати, есть ли другой способ заставить (или обнаружить) удаленный барьер? Например, я ищу в Интернете и нахожу, что другие используют FlushProcessWriteBuffers или меняют сходство, чтобы связать поток с каждым ядром. Могут ли эти трюки быть выполнены в Java?

РЕДАКТИРОВАТЬ

Я пришел с идеей. Может быть, я могу использовать GC и финализатор для реализации смещенной блокировки, по крайней мере, если есть только два потока. К сожалению, медленный путь может потребовать явного вызова gc(), что на самом деле не практично.

Если GC не точен, я могу оказаться в тупике. Если GC слишком умен и собирает мой объект до того, как я аннулирую ссылку (возможно, компилятору разрешено многократно использовать переменные стека, но разрешено ли компилятору делать такие вещи для переменных кучи, не обращая внимания на приобретение fence и load fence?), Я в конечном итоге с поврежденными данными.

РЕДАКТИРОВАТЬ

Похоже, что так называемый "забор достижимости" необходим для предотвращения перемещения оптимизатором последней ссылки объекта вверх. К сожалению, это не где.

Answer 1

Его семантика полностью состоит из того, что указано в Javadoc:

Приостановляет эту тему. Во-первых, метод checkAccess этого потока вызывается без аргументов. Это может привести к выбрасыванию SecurityException (в текущем потоке).

Если поток жив, он приостанавливается и не продвигается дальше, пока и не будет возобновлен.

Но так как вы не собираетесь использовать это, потому что это устарело, это все не имеет значения.