Сообщение Как работает SingleCheck в Dagger? от 15.01.2019 13:55
Изменено 15.01.2019 13:56 vsb
Как работает SingleCheck в Dagger?
Тут (метод get). Насколько я понимаю, это что-то вроде синглтона, но не гарантирующее единственный экземпляр, зато работающее чуть быстрей.
Меня смущает комментарий на 46-й строке: // The provider was null, so the instance must already be set
Т.е. они подразумевают, что если один поток выполнил инструкции в порядке
то во втором потоке код
отработает корректно. Для меня это не очевидно. Насколько я знаю, на x86 это может быть правдой, но на других архитектурах (например ARM) одно ядро может видеть изменения памяти в другом порядке. Правда эти поля объявлены как volatile. Означает ли это, что JVM выставит все нужные барьеры и порядок изменения volatile-переменных будет одинаковым во всех ядрах без дополнительной синхронизации?
Меня смущает комментарий на 46-й строке: // The provider was null, so the instance must already be set
Т.е. они подразумевают, что если один поток выполнил инструкции в порядке
this.instance = local;
this.provider = null;
то во втором потоке код
Provider<T> providerReference = this.provider;
if (providerReference == null) {
// The provider was null, so the instance must already be set
local = this.instance;
отработает корректно. Для меня это не очевидно. Насколько я знаю, на x86 это может быть правдой, но на других архитектурах (например ARM) одно ядро может видеть изменения памяти в другом порядке. Правда эти поля объявлены как volatile. Означает ли это, что JVM выставит все нужные барьеры и порядок изменения volatile-переменных будет одинаковым во всех ядрах без дополнительной синхронизации?
Как работает SingleCheck в Dagger?
Тут (метод get). Насколько я понимаю, это что-то вроде синглтона, но не гарантирующее единственный экземпляр, зато работающее чуть быстрей.
Меня смущает комментарий на 46-й строке: // The provider was null, so the instance must already be set
Т.е. они подразумевают, что если один поток выполнил инструкции в порядке
то во втором потоке код
отработает корректно. Для меня это не очевидно. Насколько я знаю, на x86 это может быть правдой, но на других архитектурах (например ARM) одно ядро процессора может видеть изменения памяти не в том порядке, в котором его делает другое ядро. Правда эти поля объявлены как volatile. Означает ли это, что JVM выставит все нужные барьеры и порядок изменения volatile-переменных будет одинаковым во всех ядрах без дополнительной синхронизации?
Меня смущает комментарий на 46-й строке: // The provider was null, so the instance must already be set
Т.е. они подразумевают, что если один поток выполнил инструкции в порядке
this.instance = local;
this.provider = null;
то во втором потоке код
Provider<T> providerReference = this.provider;
if (providerReference == null) {
// The provider was null, so the instance must already be set
local = this.instance;
отработает корректно. Для меня это не очевидно. Насколько я знаю, на x86 это может быть правдой, но на других архитектурах (например ARM) одно ядро процессора может видеть изменения памяти не в том порядке, в котором его делает другое ядро. Правда эти поля объявлены как volatile. Означает ли это, что JVM выставит все нужные барьеры и порядок изменения volatile-переменных будет одинаковым во всех ядрах без дополнительной синхронизации?