История изменений
Исправление Aber, (текущая версия) :
примерно как многопоток в питоне сейчас.
Стоп, с java 1.2 полноценные потоки, никакого GIL и зеленых, какой питон?
Я не понял что в Lock такого особенного? Просто помогает избегать вложенных блоков синхронизации.
volatile работало неправильно:
https://www.ibm.com/developerworks/library/j-jtp02244/ - Fixing the Java Memory Model, Part 1
Я не увидел ошибки, там говорится что volatile раньше нельзя было использовать как флаг готовности объекта, потому как состояниях других полей, не помеченные как volatile, могли отличаться от потока к потоку, т.к. изменения non-volatile могут быть не видны всем потокам сразу. А теперь в JMM добавили контракт, что если поток1 пишет в volatile поле, а поток2 читает значение этого поля, то изменениях оставшихся non-voatile полей становятся видимыми для читающего потока. А если поток3 не проверит volatile то у него могут быть не видны последние изменения в non-volatile полях.
В сях таких контрактов нету, там все зависит от железа, и наверное лучше внешние библиотеки использовать для синхронизации. А вот жаба должна исполняться одинаково на разных архитекторах, потому такой контракт и прописали.
P.S. По поводу контракта с volatile я не знал, я кажется прокачал скил для ответа по поводу volatile на интеврью, теперь еще буду про JMM добавлять. Чтож спасибо :)
Исходная версия Aber, :
примерно как многопоток в питоне сейчас.
Стоп, с java 1.2 полноценные потоки, никакого GIL и зеленых, какой питон?
Я не понял что в Lock такого особенного? Просто помогает избегать вложенных блоков синхронизации.
volatile работало неправильно:
https://www.ibm.com/developerworks/library/j-jtp02244/ - Fixing the Java Memory Model, Part 1
Я не увидел ошибки, там говорится что volatile раньше нельзя было использовать как флаг готовности объекта, потому как состояниях других полей, не помеченные как volatile, могли отличаться от потока к потоку, т.к. изменения non-volatile могут быть не видны всем потокам сразу. А теперь в JMM добавили контракт, что если поток1 пишет в volatile поле, а поток2 читает значение этого поля, то изменениях оставшихся non-voatile полей становятся видимыми для читающего потока. А если поток3 не проверит volatile то у него могут быть не видны последние изменения в non-volatile полях.
В сях таких контрактов нету, там все зависит от железа, и наверное лучше внешние библиотеки использовать для синхронизации. А вот жаба должна исполняться одинаково на разных архитекторах, потому такой контракт и прописали.