IMHO По определению

Достаточно перевести одну фразу (вариант электронного переводчика, с небольшими исправлениями):

"Atomic variables limit the scope of contention to a single variable; this is as fine-grained as you can get"

"Атомарные переменные ограничивают масштабы конфликтов одной переменной; это настолько мелкозернисто, насколько возможно"

p.s.
плохо знаю английский, но вроде "as you can get" в данном контексте, по смыслу, синоним "as possible"

Написал хохму про биты, а сейчас подумал, что "в каждой шутке, есть доля не шутки" ( C ).

На самом деле, уровень гранулярности на уровне биты, байты, переменные - процессор Intel поддерживать НЕ умеет (процессор и слова "переменные" не знает, но в любом случае гранулярность при доступе что биты, что байты для него одинаково НЕ достижима).

Что приводит к определенным проблемам при написании кода при желанием получить "as fine grained as possible" через Atomic'и, которые решаются через одно место (хотя в последней Java специальные конструкции/анотации добавили).

Поскольку автор топика уже давно читает про многопотоковость и атомики, думаю, что какой минимальный объект "as fine grained as possible" в Intel процессоре, он уже знать должен. По крайне мере, думаю, что в чужом коде "решение через одно место" он видеть уже точно должен был.

В общем, хороший теоретический вопрос на тему автора. Что же на самом деле является "as fine grained as possible" ? Это явно ни "sigle bit", ни "single byte" и соответственно не "single variable", а что-то другое (более крупное).

AFAIK

Возможно с Atomic'ами ошибаюсь.

Но с volatile переменными приходится точно идти на ухищрения, что бы они не слипались. Т.к. они слишком мелкозернисты, а процессоры (Intel) такое не поддерживают.

/ наверное "слипаются" это правильный русский глагол, для описания процесса перехода мелко зернистого объекта в более крупно зернистый ))) /

Вроде аналогично и Atomic'и. Хотя не уверен. Но вроде народ так же кучу левого кода пишет. Но это меня всегда удивляло, т.к. атомик отдельный объект, который отдельно выделяется на куче, у меня как-то всегда было изумление, неужели они могут быть настолько малы, что тоже могут слипаться.

AFAIK )))

Сформулирую свой вопрос (Дарю тем, кто проводит собеседования! Я добрый)

По определению слова "гранулярность", можно считать что самая мелькозернистая вещь в современных процессорах - это бит. Дальше, я бы расположил так:

бит
байт (8 бит)
машинное слово (для современных процессоров Intel 64 разряда)
и так далее

Если же говорить про "limit the scope of contention" то гранулярность ни бит, ни байт НЕ достижима (на современных процессорах Intel). При этом, "single variable" так же не достижима. Просто по определению и доказательству от противного. Т.к. можно сделать:

volatile char my_variable1;
volatile char my_variable2;

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

Вопрос автору топика: что же является минимально достижимой гранулярностью при доступе из нескольких потоков?

Я давно уже предупреждал автора топика, что "от многих знаний, много печалей. Поэтому тот, кто приумножает знания, приумножает скорбь" )))

В общем, прихожу к тому, что приведенная questionar цитата как минимум не корректна (использование слова/термина "переменная" при описание конкурентного доступа не к месту), а по факту полностью ложна.

Более того, я уверен, что (если абстрактный Atomic заменить на AtomicLong, JDK 1.6, современные процессоры Intel)

не все что мелкое, то достаточно мелкозернисто. И не все то, что выглядит мелкозернисто, на самом деле таким является. Более крупное, вполне может быть мелкозернистее, чем мелкое (по причине слипания)

В общем, это знают даже дети! Когда в песочнице играют в куличики.

IMHO & AFAIK

Хоть кто-то решил мне возразить. А то флудить сам с собой совершенно не интересно ))). Ну и повторюсь, я подхожу чисто с практической точки зрения. Т.к. что бы подходить с теоретической, хорошо бы однозначное определения на русском языке слов вида "гранулярность" и "мелкозернистость" для программирования.

более крупное, вполне может быть мелкозернистее, чем мелкое (из за слипаемости)
(будет настрой, напишу доказательство и определение терминов на примере песочницы и игры в куличики)

Что в свою очередь, на JDK 1.6, Intel может приводить к "ошибке слипаемости" (ошибка==проблемы вызываемые в прикладном коде эффектом самопроизвольного слипания)

Что очень хорошо известно, под английским термином False sharing.

При котором маленькие объекты (если я правильно понимаю, AtomicLong JDK 1.6 == 16 байт, НЕ проверял), с точки зрения гранулярности и мелкозернистости, могут работать ХУЖЕ, чем более крупные объекты (строка кэша 64 байт для современного Intel).





Рассматривая приведенный мною пример:

volatile char my_var1;
volatile char my_var2;
....
volatile char my_var64;

Мы, можем наивно думать, что у нас есть "fine grained" доступ или управление отдельными переменными. На самом деле, это не так! В худшем случае, все эти переменные при конкурентом доступе будут вести себя как ОДНА!

Практически, если это некоторые флаги/блокировки, то получается, что вместо 64 флагов/блокировок (якобы fine grained) мы могли бы использовать одну (пусть и не настолько fine grained) и получить такую же или, скорее всего, даже значительно лучшую производительность.



В общем не важно где произошла слипания или коагуляция потока (flow) данных и образовался осадок. Для современных серверов можно сходу назвать несколько места при доступе к RAM, где из-за коагуляции может образоваться мелководные дельты мешающие нормальному data или process flow:

1) кэш (например false sharing)
2) коллизии на шине вызванные поддержкой когеренции (полно статей, но собственно с java примеров не видел)
3) NUMA



Если на False Sharing в последней java ( JDK 1.8 ) вроде под нажимом сообщества внимание обратили, то с Numa хоть работы и проводятся, но на уровне Java Heap вроде результаты совсем не утешительные (алгоритмы реализованные в JDK 1.8 по тестам и мнению самих авторов, дают выигрыш значительно меньший, чем ожидалось теоретически и не стоят даже мускульного напряжения при вводе -numa в командной строке java ))) ).

Т.е. с Numa нужно бороться (если хочется high performance) на уровне архитектуры и настройки ОС на сервере.

На практике, сам наблюдал картину, когда из-за изменения паттерна нагрузки на потоки (перевод прикладной системы с "обычного" http на NIO /apache NIO/) при всем прочем равном (полезный бизнес код не трогался), физическая нагрузка на CPU возросла в 3-4 раза ! (а с учетом, что пробег электронов при решении бизнес кода не поменялся, это вообще феерический п...ц) при том, что количество потоков сократилось в десятки раз (кол-во одновременных соединений 150-300)

При таком степени п...ц на высоком уровне (железо, ОС, архитектура, JVM), заниматься оптимизацией и попыткой "выжать" 5-10 процентов благодаря якобы (!!!!) fined grained методам синхронизации - на мой взгляд бессмысленно.

Atomic'и написаны и хорошо выполняют конкретную задачу. Вот по этому назначению их и нужно использовать. IMHO