Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Java: Общие вопросы > Ещё раз о volatile

Автор: Рубильник 20.9.2018, 11:15

Есть у нас 2 класса, один ссылается на другой.

Код


public class Master{
    public int i=0;
    public Worker worker = null;
}

public class Worker{
    public int size=0;
    public void setSize(int _size){
        size = _size;
   }
   public int getSize(){
        return size;
   }
}

И есть у нас много потоков, которые видят экземпляр класса Master, и из него дергают метода класса Worker.
Предположим, что мы гарантируем другими средствами, что методы Worker одновременно не вызываются несколькими потоками. Нужно ли ставить volatile на переменную size, или будет достаточно поставить на переменную worker?

Формально переменную size читают и записывают разные потоки, значит как бы надо её делать volatile.
Но тогда нужно получается делать volatile ВСЕ поля ВСЕХ внутренних классов(на которые есть зависимости). У вас есть класс, который хранит "базу данных" (список Городов-Магазинов-Продавцов-Товаров- ....), то придется вешать volatile на все эти классы?
В какой момент переменная заносится в мастер копию потока?

Переменная worker не меняется, и общая для потоков.
Поток один выполнят worker.setSize(5);
затем второй поток через 1 секунду выполняет worker.setSize(10);
Опять первый поток через 2 секунды читает worker.getSize();

Есть ли возможность, что первый поток прочитает 5 из своей мастер копии, а не 10?
Есть ли возможность, что оптимизатор раскроет явно инструкции класс Worker (как inline метод), и это повлияет на работу программы.

Автор: Рубильник 20.9.2018, 11:39

Уточню свой вопрос.

Код


class A{
   public static Object syn = .... // объект для синхронизации

   public Master master = null; // переменная инициируется в конструкторе, общая для всех экземпляров и не меняет значение
   

   public  int calc(int _k){
        synchronized(syn){
            master.worker.size = _k;
        }
        ... 
        int n = 0;
        synchronized(syn){
            n = master.worker.size;
        }
        return n+_k;

   }
}

Может ли случится так, что оптимизатор, увидев, что между записью и чтением в master.worker.size ничего с этими полями не происходит, решит прочитать не из объекта, а из кеша (или мастер копии)?

Автор: LSD 20.9.2018, 13:30

Цитата(Рубильник @ 20.9.2018, 12:15

)

Предположим, что мы гарантируем другими средствами, что методы Worker одновременно не вызываются несколькими потоками.

Зависит от того, что это за средства.
Т.е. если это будет synchronized на одном и том же объекте - то тогда ВСЕ изменения (с любыми переменными) которые будут делать внутри этого synchronized блока, будут видны потокам которые потом зайдут в этот synchronized блок.

Автор: Рубильник 20.9.2018, 13:40

synchronized сбрасывает кеш? Сбрасывает при входе в блок, или при выходе из блока?

"на одном и том же объекте"
Уточните этот момент. Если synchronized идет на разных объектах, тогда как?

"будут видны потокам которые потом зайдут в этот synchronized блок"
А если блоков несколько?

Код


public synchronized void a(){
   ....
}

public synchronized void b(){
   ....
}

Будут ли изменения сделанные в методе a() одним потоком видны другому потоку в методе b()?

Что же это получается: один и тот же метод, вызванный внутри блока синхронизации и вызванный просто так, будут работать по разному? Один с общей памятью, а второй с мастер-копией. Т.е. методу есть разница где его вызвали?

Автор: LSD 20.9.2018, 16:44

Цитата(Рубильник @ 20.9.2018, 14:40

)

1. Забудь про все эти "сбрасывать кэш", "писать напрямую в память" и прочую ересь.
2. Есть https://docs.oracle.com/javase/specs/jls/se10/html/jls-17.html#jls-17.4 которая оперирует терминами видимости изменений между разными потоками. Там это описывается посредством Happens Before - если один участок кода находится в отношении Happens Before с другим - то все изменения которые произведены в первом будут видны во втором. Как это будет реализованно - установкой memory barrier , сбросом кэшей или еще как - не оговаривается. (например в случае с одноядерной x86 машиной, JVM вообще ничего не нужно делать)
3. Конкретно про synchronized - говориться что освобождение монитора Happens Before захвата этого же монитора другим тредом. Для разных мониторов такой гарантии - нет.