Информация об изменениях

Сообщение Как работает 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

Т.е. они подразумевают, что если один поток выполнил инструкции в порядке
        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

Т.е. они подразумевают, что если один поток выполнил инструкции в порядке
        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-переменных будет одинаковым во всех ядрах без дополнительной синхронизации?