Хороший пример когда volatile переменная вообще не нужна, по сути ведь теряем инфу. Это решается посредством пересылки сообщений, желательно с буффером, чем рендеву. Можно конечно по всякому задачу решить, но эффективным (быстро в run-time) решение с volatile переменной не будет, как я уже говорил, из-за не оправданных блокировок (вкйлучая железные) и отсутствию кеша. Поэтому такие сценарии исключаются в системах нацеленных на эффективную многопоточность/распределённость вычислений. Вывод: компилер не будет оптимизировать этот код (как беспоезно оптимизировать асм, кроме как простейшего pipe), он просто вам не даст писать такой (до жути не эффективный) код.


Да, пустой спор. Вот тут бенчмарки. Компилер оптимизирует согласно вложенной технике, его сила в полном "восприятии" кода, человек же способен "видеть" только ограниченный кусок. Да хотя бы шедулер комманд в декларативном языке (к примеру Haskell) так выдаст инструкции, что бы каждое выражение вычислялось не не более одного раза, к тому же лениво (по требованию). Техника доказуемая формально, это всё что нужно от человека. А компилятор способен "разжевать" массу текста и построить самое эффективное (или приближенное) решение, формально доказуемое. Гений действительно может по иному посмотреть и организовать код, но таких единицы (и они привлекаются к разработке компиляторов/языков), остальные же в силу природной лени, либо пишут не эффективный код, либо пользуются решениями высокоуровнего языка. Каждый сценарий в высокоуровневом языке доказан, эффективность решения обоснованна/доказана, поэтому в целом код почти всегда быстрей, чем аналогичный "полностью в ручную", к примеру на C.

Вам стоит заинтересоваться теорией компиляторов, построением формальных языков и среды выполнения. Тогда исчезнут домыслы о искусственном интеллекте и не оправданное недооценивание теоретических основ (программирование - наука, а не только ремесло в форм дизайнере). Впрочем быть может вы правы, нейро-сетки из ИИ области в принципе могут помочь в нахождении общей "методологии"/практики среди группы программистов одного языка, всё таки мощный это инструмент обобщения.



Не знаю с какими системами вы сталкиваетесь каждый день...  но хотя бы тот же Erlang - пример, где side-effects по моему полностью исключены.


Можно "отречься" от ранее навязанной вам техники опроса состояния (polling) и просто ждать сообщений, поверь, это гораздо эффективней, особенно если сообщения идут в своих легковесных тредах и работает всё в сетке мелких процев.


Наофтопили   

Что-то подсказывает мне, что вы пытаетесь уйти от темы (и про volatile в вопросе ничего не было). Правильный ответ - компилятор не в состоянии определить необходимость синхронизации доступа в подобном коде. Выход один - синхронизировать любые обращения (причём на уровне методов, потому как синхронизация только для копирования может нарушить логику), что приведёт к ужасающим в плане производительности результатам. Но ещё один гвоздик: синхронизация, возможно, не нужна вовсе  


Как же любят некоторые бездельники от науки раздувать целые теории из фактов, не стоящих и выеденного яйца  Sardar, программист никогда не станет (разве что от бедности) выполнять описываемые вами оптимизации - они никому не нужны. Да, компиляторы с ними справятся лучше. Чего не сможет никогда сделать компилятор - определить решаемую задачу и решить её лучше; странно, что находятся люди, решающиеся спорить на этот счёт. 


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

могла бы понадобиться

Всё уже придумано до нас (© Неизвестный автор).



Предположим, объект aa начинает доступ к этому одиночке, а следом за ним то же делает объект bb:

Если instane не объявлять как volatile, то возможен такой сценарий:
Объект aa вызывает проверку (instance == null), одиночка убеждается, что инстанции ещё нет, создаёт в памяти соответствующий объект и начинает его инициализировать, а тем временем в основную память передаётся ссылка на этот объект.
Пока идёт инициализация, объект bb вызывает проверку, в ходе которой выясняется, что инстанция существует, и получает ссылку на объект instance. Потом объект сс пытается получить importantValue, но объект instance ещё не инициализирован до конца, и cc получает неправильное значение.
Если же instance будет volatile, то ссылка на instance не будет возвращена в основную память, пока не закончится инициализация этого объекта. Таким образом, вызов от объекта bb повлечёт проверку (instance == null) которая вернёт true, и управление будет далее передано в синхронизированный блок, bb дождётся своей очереди, узнает, что объект instance уже создан, и получит ссылку на него; при этом объект будет уже полностью инициализирован, и cc таки гарантированно получит правильное значение importantValue.