Здравствуйте, a7d3, Вы писали:

N>>2012, русский, ДМК.

N>>Смешной наезд.
N>>У меня эта тема давно и прочно освоена на C/C++ на pthreads, на других языках, и чуть-чуть в ядре но именно с родными средствами C++11 до этого не приходилось сталкиваться. И у меня впечатления очень положительные: по сути, компактно, при этом с изложением не только специфики C++ в реализации средств синхронизации, но и обоснования такой специфики.
N>>Приведите пример явной "гадости" с точностью до страницы или хотя бы до главы.

A>Это не наезд,

Ну когда "Все кто хорошо отзывались — <куча уничижений>", то наезд.

A> а вопрос — полностью ли была прочитана книжка или же только местами.

Не читал справочные приложения. Остальное внимательно прочитал. Но, как уже сказал, меня интересовала исключительно специфика реализации в C++ по сравнению с уже известным.
Для полноты картины надо смотреть на качество подачи для тех, кто вообще не в теме до открытия книги. И вот тут я снова слова типа "узревшие какой-то непонятный свет в оконце схватив эту книжку в руки" считаю положительной оценкой — если для новичков в этой тематике (очень сложной и миноопасной) она полезна.

A>Автор переливает из пустое в порожнее, как пример можно взять многократную реализацию очереди или стэка. Из главы в главу и с весьма незначительными изменениями и длительными рассуждениями про них. Сделал на копейку, рассказывает так словно миллион сотворил, потом опять тоже самое, через некоторое время снова опять двадцать пять.

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

A> А уж насколько криво и косо изложено про модель памяти — это явное косноязычие. Не видно, чтобы автор пытался опереться на знакомство читателя с барьерами памяти, как их комбинирование создаёт Acquire/Release семантики.

А почему вы предполагаете 1) какое-то знакомство с "барьерами памяти" и 2) что описывать через них будет лучше (и даже просто законно)?

Барьеры совершенно не обязаны существовать в явном виде, это уже артефакт реализации. Да, в текущей архитектуре она именно такая, но это 1) не цель синхронизации, а средство, 2) может поменяться в будущем. Вся теория этой синхронизации основана на отношениях типа sequenced-before, а не на барьерах, и думать именно надо в понятиях исключения неподходящего порядка событий. Так почему автор должен был вспоминать барьеры? Это же не книга по ассемблеру, и код может, при сохранении корректности, неоднократно вывернуться наизнанку.

Здравствуйте, a7d3, Вы писали:

N>>2012, русский, ДМК.

N>>Смешной наезд.
N>>У меня эта тема давно и прочно освоена на C/C++ на pthreads, на других языках, и чуть-чуть в ядре но именно с родными средствами C++11 до этого не приходилось сталкиваться. И у меня впечатления очень положительные: по сути, компактно, при этом с изложением не только специфики C++ в реализации средств синхронизации, но и обоснования такой специфики.
N>>Приведите пример явной "гадости" с точностью до страницы или хотя бы до главы.

A>Это не наезд,

Ну когда "Все кто хорошо отзывались — <куча уничижений>", то наезд.

A> а вопрос — полностью ли была прочитана книжка или же только местами.

Не читал справочные приложения. Остальное внимательно прочитал. Но, как уже сказал, меня интересовала исключительно специфика реализации в C++ по сравнению с уже известным.
Для полноты картины надо смотреть на качество подачи для тех, кто вообще не в теме до открытия книги. И вот тут я снова слова типа "узревшие какой-то непонятный свет в оконце схватив эту книжку в руки" считаю положительной оценкой — если для новичков в этой тематике (очень сложной и миноопасной) она полезна.

A>Автор переливает из пустое в порожнее, как пример можно взять многократную реализацию очереди или стэка. Из главы в главу и с весьма незначительными изменениями и длительными рассуждениями про них. Сделал на копейку, рассказывает так словно миллион сотворил, потом опять тоже самое, через некоторое время снова опять двадцать пять.

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

A> А уж насколько криво и косо изложено про модель памяти — это явное косноязычие. Не видно, чтобы автор пытался опереться на знакомство читателя с барьерами памяти, как их комбинирование создаёт Acquire/Release семантики.

А почему вы предполагаете 1) какое-то знакомство с "барьерами памяти" и 2) что описывать через них будет лучше (и даже просто законно)?

Барьеры совершенно не обязаны существовать в явном виде, это уже артефакт реализации. Да, в текущей архитектуре она именно такая, но это 1) не цель синхронизации, а средство, 2) может поменяться в будущем. Вся теория этой синхронизации основана на отношениях типа happens-before, а не на барьерах, и думать именно надо в понятиях исключения неподходящего порядка событий. Так почему автор должен был вспоминать барьеры? Это же не книга по ассемблеру, и код может, при сохранении корректности, неоднократно вывернуться наизнанку.