redwhite90...
Integer x[] = {1, 2, 3, 4, 5, 6, 7, 8, 9};
...


эта переменная должна быть finall - вы же её в другой поток передаете.

ivanraНу, во-первых, хотя программа и многопоточная, выполняться она будет строго последовательно.
Во-вторых, ошибки вроде быть не должно, возможно, проблема в конкретной версии jvm, уточните, что используете

Почему это? Насколько я понимаю тут будет 3 потока: 1 основной и по одному для каждого задания

Blazkowicz_quark_эта переменная должна быть finall - вы же её в другой поток передаете.
LOL. Ничего что она локальная? И сама переменная не модифицируется.

В том то и дело, что она локальная. Модель памяти Java не гарантирует, что x[] будет инициализирована раньше, чем начнут выполнятся новые потоки.
finall это гарантирует. Почитайте Java Concurrency in Practice - узнаете много нового.

BlazkowiczВы наверное про поле CallableClass ?
Нет я имел ввиду именно локальную переменную x метода main. А именно то, что она может передаться новым потокам непроинициализированной.

Blazkowicz_quark_finall это гарантирует. Почитайте Java Concurrency in Practice - узнаете много нового.
Здесь гонок нет. Если даёте ссылку то давайте на конкретную главу, хотя бы. А так пальцем в небо. Читал. Узнал много нового. Как это применяется к указанному коду?

Глава 3.5. Safe Publication

3.5.1. Improper Publication: When Good Objects Go Bad
You cannot rely on the integrity of partially constructed objects. An observing thread could see the object in an inconsistent state, and then later see its state suddenly change, even though it has not been modified since publication.

In fact, if the Holder in Listing 3.15 is published using the unsafe publication idiom in Listing 3.14, and a thread other than the publishing thread were to call assertSanity, it could throw AssertionError![15]

_{[15] The problem here is not the Holder class itself, but that the Holder is not properly published. However, Holder can be made immune to improper publication by declaring the n field to be final, which would make Holder immutable; see Section 3.5.2.}

Listing 3.15. Class at Risk of Failure if Not Properly Published.



Because synchronization was not used to make the Holder visible to other threads, we say the Holder was not properly published. Two things can go wrong with improperly published objects. Other threads could see a stale value for the holder field, and thus see a null reference or other older value even though a value has been placed in holder. But far worse, other threads could see an up to date value for the holder reference, but stale values for the state of the Holder. ^[16] To make things even less predictable, a thread may see a stale value the first time it reads a field and then a more up to date value the next time, which is why assertSanity can throw AssertionError.

_{[16] While it may seem that field values set in a constructor are the first values written to those fields and therefore that there are no "older" values to see as stale values, the Object constructor first writes the default values to all fields before subclass constructors run. It is therefore possible to see the default value for a field as a stale value.}

At the risk of repeating ourselves, some very strange things can happen when data is shared across threads without sufficient synchronization.

...

3.5.2. Immutable Objects and Initialization Safety

...

To publish an object safely, both the reference to the object and the object's state must be made visible to other threads at the same time. A properly constructed object can be safely published by:
Initializing an object reference from a static initializer;

Storing a reference to it into a volatile field or AtomicReference;

Storing a reference to it into a final field of a properly constructed object; or

Storing a reference to it into a field that is properly guarded by a lock.


В данном случае локальная переменная x метода main как раз публикуется (передается конструкторам CallableClass) не безопасно. Поэтому другие потоки могут увидеть её в непроинициализированном состоянии. final обеспечивает безопасную публикацию.

забыл никв данном случае отвественность за безопасную публикацию берет на себя ExecutorService.

ExecutorService берет на себя ответственность за безопасную публикацию только экземпляров CallableClass. Локальная переменная x метода main опубликована небезопасно - поэтому значением поля x экземпляров CallableClass потоки могут увидеть самые странные значения.

забыл никУгу, сразу после конструирования, которое идет после инициализации массива, и оба действия происходят в одном потоке, сохраняя при этом total order of execution. Этакий piggybacking.

Именно. Модель памяти java при многопоточности так и работает. Потоки задач уже могут выполнять CallableClass.call(), а локальная переменная x метода main может быть все-еще непроинициализированна.

BlazkowiczПо вашему этот массив может быть не до конца инициализирован?
Да.

BlazkowiczРечь исключительно о полях и объектах.
Массив x это объект (аналогично экземпляру класса Holder из примера). Потоки заданий могут увидеть его в непроинициализированном состоянии.

schwa_quark_В данном случае локальная переменная x метода main как раз публикуется (передается конструкторам CallableClass) не безопасно. Поэтому другие потоки могут увидеть её в непроинициализированном состоянии. final обеспечивает безопасную публикацию.
И почему тогда вот этот Holder публикуется не безопасно?


Ведь можно делать так и ...


и все состояние Holder-а безопасно опубликовано.

В примере Holder вообще не публикуется.
Публикация происходит тогда, когда экземпляр класса Holder будет передается другому потоку.
Если вы опубликуете объект класса Holder безопасно - то все будет ОК. Если нет, то другой поток может увидеть этот объект в состоянии, когда выполнение конструктора этого объекта в основном потоке еще не закончилось.

Blazkowicz_quark_Потоки задач уже могут выполнять CallableClass.call(), а локальная переменная x метода main может быть все-еще непроинициализированна.
"непроинициализировання" переменная это ссылка на null. Т.е по вашему локальная переменная на стеке, вместо ссылки на массив будет почему-то содержать ссылку на null? И этот null будет использован при вызове конструктора CallableClass в том же методе?
Звучит как бред?
Еще веселее. Т.к. локальные переменные не инициализируются значениями по умолчанию, то локальная переменная x может содержать ссылку на "недостроенный" массив (т.е. этот самый массив может как раз инициализироваться основным потоком, когда поток задачи к нему обращается).

BlazkowiczИли речь таки об инициализации массива и его публикации? Т.е. массив может быть не заполнен? Но как это связано с финальностью локальной переменной?
С final фича в том, что если локальную переменную x объявить finall , то она сначала проинициализируется, а уже только потом эта переменная будет использоваться в new CallableClass(x, 0, 5).

BlazkowiczНо final таки влияет на состояние самой ссылки. На процесс инициализации элементова массива он никак не влияет.
Как раз таки влияет, но именно при инициализации. Если после один из элементов массива будет изменен в одном из потоков, то другие потоки могут продолжить видеть старое содержимое массива.

Опять же в Java Concurrency in Practice это описывается в Chapter 16. The Java Memory Model. Есть так называемые правила happens before

16.2.2. Safe Publication
The safe publication idioms described in Chapter 3 ensure that the published object is visible to other threads because they ensure the publication happens before the consuming thread loads a reference to the published object.

если переменную локальную переменную x объявить finall, то тем самым мы её безопасно опубликуем для потоком задач и таким образом потоки гарантированно будут видеть её в проинициализированном состоянии.

schwaИ каким тут образом тогда в примере из стартового сообщения получается небезопасная публикация содержимого массива, если состояние коллабл, публикуется безопасно экзекутором?
Грубо говоря поле x объектов CallableClass будет ссылаться на тот же адрес в памяти, что и локальная переменная x в момент обращения к ней. Однако эта содержимое массива по этому адресу может еще только инициализироваться в основном потоке, когда новые потоки уже начнут к нему обращаться.

Безопасная публикация объектов CallableClass, означает что когда потоки задач смогут обратиться к объектам CallableClass - для этих объектов уже будет выполнен конструктор.

забыл ник_quark_,

Вы не правы в данном случае.

Рассмотрим по порядку -
1) идет инициализация массива и присваивание переменной ссылки на него
2) идет конструирование Callable в ТОМ же потоке, модель памяти java гарантирует что компилятор никак не должен ломать total execution of order внутри исполнения ОДНОГО потока, таким образом Callable будет гарантировано сконструирован правильно.
3) Далее мы ложим Callable в экзекьютор и экзекьютор сам уже заботится о публикации ссылки на Callable
Таким образом код абсолютно корректен. А вот если бы массив был параметром к методу, или полем класса - тогда да, возможны варианты, потому что непонятно в каком потоке он был создан.

Обратите внимание, что модель памяти Java гарантирует, что для одного потока код ведет себя так, словно выполняется последовательно. На самом деле порядок выполнения инструкций может изменяться (см. Java Concurrency in Practice Chapter 16. The Java Memory Model).
16.1. What is a Memory Model, and Why would I Want One?

...

The Java Language Specification requires the JVM to maintain within thread as if serial semantics: as long as the program has the same result as if it were executed in program order in a strictly sequential environment, all these games are permissible
Там же написано и то, зачем это делается.

1) может быть как раз наоборот: сначала в переменную будет записан указатель на адрес в памяти, а потом только массив будет проинициализирован
2) в поле x экземпляра Callable может быть записан указатель на тот же адрес в памяти, на который указывает локальная переменная x. При этом инициализация массива все-еще отложена (ведь экземпляр Callable в основном потоке к содержимому массива вообще не обращается)
3) экзекьютор безопасно публикует объект Callable - ссылка остается той же самой. То что он записывает в полю x экземпляра Callable тот же самый адрес, что содержит локальная переменная x, еще не означает, что массив уже должен быть проинициализирован - ведь к содержимому этого массива в основном потоке никто не обращается.

Итого в основном потоке инициализация массива может произойти например в самом конце метода main. В пределах основного потока - это допустимо, т.к. основной поток вообще не обращается к содержимому массива.
А потоки задач могут видеть массив непроинициализированным.

Если в конструкторе коллабл мы обращаемся к массиву, содержимое которого еще не инициализированно, то компилятор должен был преобразовать наш код в что-то следующее


А это некорректное преобразование, которое нарушает порядок выполнения программы - ведь инструкции, которые бы заполнили бы массив, были пропущены, а они должны были быть выполнены еще до завершения конструктора коллабл.[/quot]
Вполне может быть и что-то вроде того, что Вы описали (и еще много чего еще).
И как раз из-за этого и может произойти ошибка вроде:
redwhite9000005
Смещение исключения: 000000000009970a
Версия ОС: 6.1.7601.2.1.0.256.1
Код языка: 1049
Дополнительные сведения 1: 4c0d
Дополнительные сведения 2: 4c0d4d78887f76d971d5d00f1f20a433
Дополнительные сведения 3: 4c0d
Дополнительные сведения 4: 4c0d4d78887f76d971d5d00f1f20a433

Неправильно процитировал.
schwaЕсли в конструкторе коллабл мы обращаемся к массиву, содержимое которого еще не инициализированно, то компилятор должен был преобразовать наш код в что-то следующее
...
А это некорректное преобразование, которое нарушает порядок выполнения программы - ведь инструкции, которые бы заполнили бы массив, были пропущены, а они должны были быть выполнены еще до завершения конструктора коллабл.

Вполне может быть и что-то вроде того, что Вы описали (и еще много чего еще).
И как раз из-за этого и может произойти ошибка вроде:
redwhite9000005
Смещение исключения: 000000000009970a
Версия ОС: 6.1.7601.2.1.0.256.1
Код языка: 1049
Дополнительные сведения 1: 4c0d
Дополнительные сведения 2: 4c0d4d78887f76d971d5d00f1f20a433
Дополнительные сведения 3: 4c0d
Дополнительные сведения 4: 4c0d4d78887f76d971d5d00f1f20a433

schwa_quark_Неправильно процитировал.
пропущено...


Вполне может быть и что-то вроде того, что Вы описали (и еще много чего еще).
И как раз из-за этого и может произойти ошибка вроде:
пропущено...

Нет. Это баг JVM. А то, что я написал это нарушение последовательного выполнения программы, которое не может возникнуть сейчас. И никакое final у переменной не влияет в примере ни на что абсолютно. К тому же в JMM всеми этими фичами наделены исключительно поля. См. 17.5. final Field Semantics Java Spec

Вы правы.