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?

EDIT

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

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

EDIT

Кажется, так называемый «достижимость забор» необходим для предотвращения оптимизатора moveing ​​последней ссылки объекта вверх. К сожалению, это не где.

Answer 1

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

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

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

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