no56892 ,
Вы сути не уловили. Цикл здесь стоит для того, что бы показать, что второй поток не видит изменений первого неограниченно долгое время. Как вы можете объяснить причину этого? Почему я читаю переменную вновь и вновь, но не вижу в ней 1?

mesier ,
Откровенно говоря, буквально каждое предложение неверно :-) Попозже отвечу, когда время будет.

mesierMultithreading - параллельное, или псевдопараллельное (если всего один процессор) выполнение разного или одинакового кода в потоках операционной системы. Потоки отличаются от процессов тем, что выполняются в пределах одного адресного пространства памяти, выделенного на процесс.Да.
mesierConcurrency - один из способов синхронизации работы потоков, для согласования работы с общими данными, к которым обращается код из потоков.Нет. Канкарренси - это общение потоков в целом. Она не предполагает обязательную согласованность данных. Например, вы можете встретить намеренную несогласованность данных (data races) в классах java.util.concurrent (AbstractQueuedSynchronizer, ConcurrentHashMap, etc.). Но наличие этих несогласованностей не делает этот код "не конкурентным". Он еще какой конкурентный :-)

mesierВообще, весь этот способ стал актуальным с появлением многопроцессорных машинНет. Если говорить конкретно про проблемы согласованности данных, то они возникают и на однопроцессорных машинах благодаря оптимизациям JIT-компиляторов. Так что суди о актуальности этой проблемы по количеству процессоров - неверно.

mesierВообще, весь этот способ стал актуальным с появлением многопроцессорных машин, а возможен стал благодаря появлению, сначала на RISC-овых процессорах, затем на x86 (кажется начиная с 586, или иначе "пентиум"), команды процессора casa и cmpxchg соответственно - или иначе CAS (compare-and-swap). Это атомарная операция. Атомарность гарантируется тем, что после считывания данных из ячейки памяти не освобождается шина данных, а сначала происходит сравнение, изменилось ли содержимое ячейки памяти.Нет. Разграничивать работу кода можно и без атомарных операций. Например, см. алгоритм Петерсона, для его корректной работы на современных процессорах достаточно обычного volatile. Более того, не все арзитектуры имеют CAS в принципе. На некоторых реализован другой подход - LLSC, обладающий своими преимуществами. Например, отсутсвием ABA-проблемы. В любом случае, псиать конкурентных код можно и без CASов.

mesierДругой способ обеспечить эксклюзивный доступ к общей памяти - synchronizing - основан на использовании мьютексов операционной системы, и заключается фактически к установке последовательного, поочередного выполнения участков синхронизированного кода. Когда код входит в синхронизированный блок кода, он проверяет мьютекс, и если он установлен, то ждет освобождения.Если вы про ключевое слово synchornized, то неверно. Прежде, чем Java обратится к ОС за помощью она предпримет огромное количество действий, что бы этого избежать. Почитайте про thin и fat мониторы, и про biasing. Именно факт того, что в отсутствие contention synchronized не лезет в ОС делает его самым быстрым решением среди всех остальных других. А в присутствии contention он начинает проигрывать ReentrantLock.

mesierНа "несильно параллельных" многопоточных приложениях можно обеспечить эксклюзивный доступ к данным, и избежать ситуаций гонки, с помощью объявления совместно используемых переменных с ключевым словом volatile - в ряде случаев этого может оказаться достаточно.Нет. volatile не обеспечивает эксклюизвный доступ к памяти. Она лишь обеспечивает видимость изменений между потоками с помощью барьеров памяти. Таким образом, volatile синхронизирует состояние памяти между потоками, но не синхронизирует порядок доступа к памяти этими потоками.

mesierОбъявление переменной с ключевым словом volatile гарантирует, что при модификации данных, значение будет записываться непосредственно в память, а не в кэш.Нет, об этом я уже писал выше. volatile никак не влияет на расположение объектов в кэше. Кэшируется абсолютно все. volatile накладывет ограничение на то, какие оптимизации можно проводить с переменной. Например, как я уже писал выше, ее нельзя кэшировать в регистре. Нельзя игнорировать ее чтения. И т.д.. А JIT очень любит заниматься такой ерундой :-) Поэтому, volatile чтение медленнее обычного чтения не потому, что "переменной нет в кэше, и ее долго читать из памяти". Она есть в кэше. А потому, что JIT не имеет права применять к ней свои оптимизации.

0FDТогда и про control и s обьясните, в чем отличие.Мой ответ такой - я не знаю, почему второй поток не видит s = 1 :-) Самый лучший способ достоверно это узнать - обратиться к Шипилеву/Куксенко/Иванову/Дагу.

mesierDEVcoach, ну, теперь я вижу, что "на верхнем уровне абстракции" я всё-таки правильно рассказал. Вам просто до%%%ться захотелось.. ))Ну если:
1) Сказать, что volatile не кэшируются, хотя они кэшируются;
2) Сказать, что volatile обеспечивает эксклюзивный доступ к данным, хотя она не делает этого;
3) Сказать, что конкарренси возможна только при наличии CAS, хотя это не так;
и т.д. это по-вашему "до@баться к мелочам", то пусть будет так :-)

0FDПро s=1 понятно, я про control почему изменения control в одном потоке, видны другому, в отличии от s.x86 достаточно консервативна в возможных реордерингах на железном уровне: TSO. Поэтому по-хорошему за редким ислключением все должны видеть всех. Поэтому я склонен винить в "невидимости" s JIT, а не железо. Судя по всему, он не посчитал нужным записать новое значение s в память. Но это только догадка.

0FDПолучается System.out.println является Synchronization actions которое заставляет читать s=1, такое Synchronization actions заставляет читать counter в другом потоке. Первым Synchronization actions является Thread.start, и во второй поток считывается s=0Нет. Вы сейчас пытаетесь объяснить это, основываясь на ваших знаниях работы Java. Но вы не учитываете то, что много чего еще не знаете.
Вернее, если быть точным, вы пытаетесь подогнять ваши знания под наблюдаемое поведение. Так лучше не делать. sout не является synchronization action. Но это как минимум системный вызов, который обращается к ядру операционки, порождает context switch, и т.д.. В процессе этой сложной последовательности действий каким-то образом данные между потоками всетаки синхронизируются. Но почему это происходит - большой вопрос. Поэтому нельзя сказать, что sout это synchronization action.

0FD ,

Вы меня неправильно поняли :-) Под "много чего не знаете", я имел ввиду в первую очередь внутреннее устройство операционки, железа, и прочих низкоуровневых вещей. Говоря "вы много чего не знаете", я не претендую на то, что я это знаю. Вы привели в пример sout, и смогли найти этому объяснение. Отлично. Но во-первых, это не полное объяснение, т.к. с точки зрения JMM в этом случае есть acquire в читающем потоке, но нет release в пишущем.
Во-вторых, есть масса других способ заставить этот поток увидеть s=1. Например, как уже приводили выше пример, с помощью Thread.yield(). Как вы объясните, что видимость появляется в этом случае? Это нативный метод, к synchronization action не относится ... а видимость дает?
Наконец, к synchronization action относят только то, что указано в JMM, базовые кирпичики. Все, что свыше - это не новые sync actions, а лишь надстройки над имеющимися.