Я, конечно, не знаю, но так тоже никто уже не пишет на С++
Snd * snd = new Snd (10);
...
delete snd;
Автор несколько устарел, отсюда и делает неправильные выводы. Правильно писать так:
std::unique_ptr<Snd> snd(new Snd(10));
Более того, Snd тоже неправильно реализован. Там тоже надо использовать умные указатели. Т.к. unique_ptr не использует атомарные операции, то также неправильный вывод о том, что будут проблемы в многопоточных средах.
Каждое увеличение и уменьшение счетчика требует блокировки! Эта блокировка обычна реализуется с помощью атомарных переменных, но есть еще и мьютексы! Не позволяйте себя обмануть: доступ к атомарным переменным обходится дорого.
Кручу, верчу, обмануть хочу. Сначала говорится про блокировки, потом про атомарность, потом про мьютексы и опять блокировки. Так это, нужны блокировки для счетчиков или нет? Тумана много напустили. И да, обмануть мы себя не позволим: при отсутствии большой конкуренции к атомарным счетчикам такая операция стоит очень дешево. И не надо лохматить бабушку!
Ну с тем же успехом можно было привести в качестве примера лазер. Там создается инверсная заселенность, а значит «отрицательная температура».
2-квантовая физика-это вообще одна большая неравновестность и как пример, виртуальные частицы-частицы, которые самопроизвольно рождаются и погибают за время меньше 10^-20 секунд. Вспомните ещё и про отрицательную энергию и про экранирование виртуальными частицами заряда у реальных частиц и т.п.
Квантовая физика и неравновесность — это вообще ортогональные понятия. Квантовые законы оперируют с состоянием, который в классической интерпретации приводит к вероятностям. Там вообще понятие температуры ни разу не вводится. По крайней мере я не помню, чтобы нам хоть раз говорили про температуру на квантах.
Главное — не нести чушь. Отрицательной температуры не бывает. Бывает отрицательная «эффективная» температура. Температуру нельзя ввести для состояний не в равновесии. Рекомендую почитать википедию в качестве введения.
Не знаю, но может слышали, есть такие устройства, токамаками называются. Там температура, грубо, 1КэВ, что примерно 10 000 000 К (или С, уже не важно).
Короче, так: от тела может быть 2 источника: отраженный свет, и излученный свет самим телом. Так вот, у абсолютно черного тела нет отраженного света. При этом излучение есть всегда, т.к. при температуре > 0K имеется движение, что вызывает электромагнитное излучение.
Температура — это понятие из термодинамики. Т.е. должно быть равновесие по каким-то степеням свободы. Если его нет — то нельзя ввести и температуру. Но если очень хочется, то можно. Но тогда говорят об «эффективной» температуре, и она может быть какой угодно.
На самом деле нет. В этом «идеале» нет composability.
Судя по всему, вы пропустили слово «практически». Я не настаиваю на том, что это — идеал, но очень близко к нему. Этот пример приведен в качестве затравки. Более того, моя статья посвящена несколько другим аспектам, где этот недостаток («composability») сильно сглажен (см. комментарий).
Пример: мы пишем сервер, поток, принявший запрос, определяет по round robin алгоритму, какому именно потоку делигировать выполнение запроса, затем кладет в запрос в входящую очередь этого потока, далее, обработка запросов может выполняться поэтапно несколькими потоками используя pipeline парралелизм.
Выше приводился пример про кешировние, когда использование такого подхода для доступа к данным приводит к дополнительным накладным расходам.
В общем, цель, это обычно баланс между fine и coarse granularity, а данный подход как раз фокусируется только на первом. Это полхо.
С тем же успехом можно сказать, что я в своей статье использовал С++ и ничего не сказал про Java, а это плохо. Или что ничего не сказал о conditional variable или атомарных конструкциях. Странный аргумент. Вместе с тем, подход не исключает использование coarse granularity. Для этого всего лишь нужно создать один An(RW)Lock объект, не включающий в себя другие An(RW)Lock объекты.
Кому-то ещё охота возиться с кучей локов и мутексов, корректно и быстро работать с которыми получается практически никогда?
У меня практически всегда удается корректно и быстро работать. Что я делаю не так?
Уж либо использовать атомарные примитивы, либо строить приложение на базе более высокоуровневых конструкций вроде тредпулов с фьючерами, очередей с производителями/потребителями или fork/join (одно не исключает другого).
Очень сильно зависит от задач. Если правильно шарить данные, то никаких проблем не бывает. И мне очень интересно узнать, как реализовать, например, консистентное кеширование данных в памяти с использованием фьючерсов или тредпулов.
То, что было приведено выше — это не «полезная идиома», а пример, который иногда используют (см. [9] Хабрахабр: Многопоточность, общие данные и мьютексы). В приведенной статье такое сделать просто невозможно.
А дело в том, что такой код будет большую часть времени заниматься захватом и возвращением мьютексов в ядре ОС, вместо того, чтобы выполнять свои прямые обязанности.
Не совсем понятно, как предлагается работать: без мьютексов? Или имелось в виду частое использование? Для этого описаны способы, как оптимизировать использование.
Поэтому, я считаю, некоторые вещи лучше делать явно.
Ну на этот счет есть разные мнения. Возможно, что вам подойдет С-подход: там надо все делать явно. Вы скорее всего подразумеваете, что scoped-локи — это тот уровень автоматизма, дальше которого не стоит продвигаться. Я так не считаю, т.к. чем больше будет делать за тебя компилятор — тем лучше. Если возникнет проблема производительности, то всегда имеется возможность заоптимизировать. Более того, современные реализации мьютексов лезут в ядро только когда объект действительно занят, причем достаточно длительное время.
shared_ptr — это тоже магия. Мало кто знает, как он на самом деле работает. Но тем не менее, его используют и ничего. И на его тормоза тоже смотрят сквозь пальцы. Так что все зависит от задач и общего рецепта я бы не давал. Я лишь рассмотрел подход к штанге многопоточности с другой стороны.
С тем же успехом можно сказать: зачем нам C++, когда все можно написать C. Безусловно, можно. Вопрос в простоте и удобстве, в качестве и предсказуемости.
И не будет ли в реальном проекте куча такого кода?
Ну если в реальном проекте не смущает использование "." или "->" в приведенных операциях, то я не вижу ничего зазорного использовать --->. Но это — на любителя, конечно.
С COW — вообще отдельная песня.
Да, это — не панацея. Собственно, в статье детально изложены плюсы и минусы использования.
В целом, инкапсуляция локов, конечно же, самый предпочтительный вариант. Но у него есть один недостаток, который отсутствует в приведенном подходе: это то, что нельзя атомарно сделать несколько операций. Для примера, возьмем Counter и инкапсулируем локи для всех его методов. Тогда возникает вопрос: а как мне атомарно увеличить счетчик на 100? Ответ — делать новый метод и тогда все получится. Но ведь существует еще массу других вариантов использования: уменьшить на число, удвоить, утроить и т.п. Что, добавлять каждый такой метод в класс? Более того, не всегда нужно использовать Counter с учетом многопоточности, иногда просто хочется его использовать в одном потоке.
В описанном подходе просто используем WAccess и сразу получаем результат. Хочется — можно использовать AnLock, а можно и AnRWLock или даже AnCow. Т.е. гораздо большая гибкость, плюс автоматом берутся локи, т.е. не надо в каждый метод напихивать scoped-локи.
В любом случае, выбирать, какой метод использовать целиком и полностью ложится на плечи программиста. Мне хотелось привести более другие подходы к частым вопросам многопоточности.
Таким образом, Белл настаивал на важности «экспериментов типа предложенного Аароновым и Бомом, в котором настройки изменяются во время полета частиц» (эта идея ранее уже была высказана в книге Бома). В таком динамическом эксперименте условие локальности должно быть следствием причинности по Эйнштейну с учетом сверхсветового влияния.
Как показано в наших предложениях (1975г.), достаточно переключать каждый поляризатор между двумя положениями (a и a' для I, b и b' для II).
И где там случайность в этом динамическом эксперименте?
Ок. Теперь вопрос: зачем нам случайным образом выбирать A поляризацию, B поляризацию и C поляризацию? И когда происходит измерение, где в этот момент случайность? Какому наблюдению/измерению случайность поляризаций соответствует? Вы представляете как в таком случае должен выглядеть эксперимент со «случайными характеристиками», т.е. со случайным выбором угла поляризации, причем случайно для двух разных квантов? Как это вообще должно выглядеть?
Покажите, где в этой статье написано про случайность характеристик? Я такого не нашел.
Опять же, речь была не про какие-то эксперименты, а про те, которые согласуются с вашей постановкой задачи, т.е. где измеряются именно случайные характеристики.
Автор несколько устарел, отсюда и делает неправильные выводы. Правильно писать так:
Более того, Snd тоже неправильно реализован. Там тоже надо использовать умные указатели. Т.к. unique_ptr не использует атомарные операции, то также неправильный вывод о том, что будут проблемы в многопоточных средах.
Кручу, верчу, обмануть хочу. Сначала говорится про блокировки, потом про атомарность, потом про мьютексы и опять блокировки. Так это, нужны блокировки для счетчиков или нет? Тумана много напустили. И да, обмануть мы себя не позволим: при отсутствии большой конкуренции к атомарным счетчикам такая операция стоит очень дешево. И не надо лохматить бабушку!
Квантовая физика и неравновесность — это вообще ортогональные понятия. Квантовые законы оперируют с состоянием, который в классической интерпретации приводит к вероятностям. Там вообще понятие температуры ни разу не вводится. По крайней мере я не помню, чтобы нам хоть раз говорили про температуру на квантах.
Выше приводился пример про кешировние, когда использование такого подхода для доступа к данным приводит к дополнительным накладным расходам.
С тем же успехом можно сказать, что я в своей статье использовал С++ и ничего не сказал про Java, а это плохо. Или что ничего не сказал о conditional variable или атомарных конструкциях. Странный аргумент. Вместе с тем, подход не исключает использование coarse granularity. Для этого всего лишь нужно создать один An(RW)Lock объект, не включающий в себя другие An(RW)Lock объекты.
Очень сильно зависит от задач. Если правильно шарить данные, то никаких проблем не бывает. И мне очень интересно узнать, как реализовать, например, консистентное кеширование данных в памяти с использованием фьючерсов или тредпулов.
Ну на этот счет есть разные мнения. Возможно, что вам подойдет С-подход: там надо все делать явно. Вы скорее всего подразумеваете, что scoped-локи — это тот уровень автоматизма, дальше которого не стоит продвигаться. Я так не считаю, т.к. чем больше будет делать за тебя компилятор — тем лучше. Если возникнет проблема производительности, то всегда имеется возможность заоптимизировать. Более того, современные реализации мьютексов лезут в ядро только когда объект действительно занят, причем достаточно длительное время.
shared_ptr — это тоже магия. Мало кто знает, как он на самом деле работает. Но тем не менее, его используют и ничего. И на его тормоза тоже смотрят сквозь пальцы. Так что все зависит от задач и общего рецепта я бы не давал. Я лишь рассмотрел подход к штанге многопоточности с другой стороны.
Ну если в реальном проекте не смущает использование "." или "->" в приведенных операциях, то я не вижу ничего зазорного использовать --->. Но это — на любителя, конечно.
Да, это — не панацея. Собственно, в статье детально изложены плюсы и минусы использования.
В описанном подходе просто используем WAccess и сразу получаем результат. Хочется — можно использовать AnLock, а можно и AnRWLock или даже AnCow. Т.е. гораздо большая гибкость, плюс автоматом берутся локи, т.е. не надо в каждый метод напихивать scoped-локи.
В любом случае, выбирать, какой метод использовать целиком и полностью ложится на плечи программиста. Мне хотелось привести более другие подходы к частым вопросам многопоточности.
И где там случайность в этом динамическом эксперименте?
Опять же, речь была не про какие-то эксперименты, а про те, которые согласуются с вашей постановкой задачи, т.е. где измеряются именно случайные характеристики.