Почему отсутствие объектов синхронизации, которые являются постоянным источником багов, лучше их наличия — надеюсь, объяснять излишне.
А вот что касается задержек — это очень хороший вопрос. Вкратце, в рамках такого подхода нужно мыслить немного другими категориями. Об этом я постараюсь рассказать в статье о проектировании программ через конвейерные потоки.
В этом наверное тоже есть смысл, но на мой взгляд это слишком «тяжёлое» решение. Потому что оно тянет за собой сокеты, таймеры и прочее. Допускаю что в ряде случаев оно вполне оправдано.
Надеюсь Вы извините меня за мой велосипед и как попытку сделать достаточно лёгкое и универсальное решение с минимумом зависимостей.
Что касается кода — то это, вообще говоря, практически любая многопоточная программа.
Например, GUI в параллели с которым идёт обработка.
Скажем, в моей области (управление технологическими процессами) с применением GUI. GUI — как правило, главный поток, кроме него есть поток, который «принимает решения» по генеральному управлению линией, а также потоки журнала, потоки обмена с контроллерами узлов линии, потоки обмена для синхронизации по сети. Всего порядка 10-12 штук, которые активно взаимодействуют друг с другом посредством асинхронных сообщений. Например, поток журнала, с которым взаимодействуют все. Или поток сетевой синхронизации, который делает запросы в журнал не только для чтения/записи, но и для запросом на кэширование определённых записей в целях ускорения инкрементальной синхронизации журналов по сети.
Или «принимающий решения» поток активно взаимодействует с GUI, но при этом не может позволить в нём постоянные локи — очень нехорошо отражается на взаимодействии с пользователем.
Страшно представить, сколько бы понадобилось отлаживать без асинхронных сообщений.
Или вот пример попроще. Веб-сервер, который на каждый тип задания или пользователя рождает Worker. А сам Worker — конвейерный поток, который отвечает на запросы и выполняет полезную работу. Без необходимости в излишней синхронизации.
Вижу основную заслугу статьи в том, что показано как избавиться от объектов синхронизации, введя определённые ограничения на код. Что касается реализации очереди, то она может быть самой разной (я например свою «допиливал» примерно полгода, после чего получил вполне эффективное решение, не требующее, к тому же, постобработку кода).
По крайней мере, я поставил на повестку дня многопоточные программы без мьютексов и семафоров. Со всеми их плюсами и минусами. Это немного другой подход к многопоточности, который, в идеале, я и стремлюсь обсудить. Надеюсь сделать это в следующей статье, которая будет посвящена исключительно этому, где не придётся размениваться на описание что такое конвейерные потоки.
Возможно, надо требовать оплату вперёд от покупателя. Но не сразу на счёт заказчика, а после подтверждения покупателем получения товара. В общем, да, в стиле пэйпал.
Почему-то автор учёл всевозможные варианты набора, кроме самого основного: ввод «Россия», наиболее естественный для любого простого пользователя, никак не обрабатывается. И можно сколько угодно объяснять про локали и технические сложности, но пользователь ни о чём не знает. Он только сердится, когда не может набрать название своей страны на понятном ему языке.
Вы правы, а я ошибся.
Конечно, в этом случае во весь рост встаёт проблема нормализации URL (а она вовсе не тривиальна, как вы понимаете) — но, пожалуй, это меньшее из зол.
Множественным наследованием пользуюсь. В реальных коммерческих проектах, которые поддерживаю годами.
Зачем? Во-первых, частично реализованные интерфейсы (иногда экономит массу кода). Во-вторых, по прямому назначению.
Да, это крайне мощный инструмент, а значит им надо уметь очень аккуратно пользоваться.
Это и неудивительно. С++ весь такой.
Кстати, и виртуальным наследованием также пользуюсь. Тоже стараюсь очень аккуратно.
Когда есть смысл заменить наследование на включение объекта в класс, всегда это делаю. Потому что наследование — гораздо более сильная форма сцепления, чем включение в класс. Если кого интересует подробнее, рекомендую внимательно почитать Голуба.
Извините, не согласен.
Для многих /простых/ людей, yandex@ya.corp.ru (даже если они туда и посмотрят), выглядит вполне респектабельно. И так будет продолжаться ещё долго, потому что простой пользователь очень далёк от этих «тонкостей». Как бы нам, айтишникам, ни хотелось обратного.
Вот. А потому что веб-формы в онлайн-почте — это в принципе дыра в безопасности.
В письме нужно вырезать весь скрипт и формы. Увы. Иначе вот такое никогда не кончится.
А ссылки надо «переписывать» через внутренний редирект, который «обнуляет» куки.
фотон находится в нескольких состояниях(неопределенность) до тех пор пока наблюдатель не проводит наблюдение за ним. в тот момент, когда произошло наблюдение, фотон принимает строго известное положение
Мой вопрос остаётся прежним: откуда фотон (или не фотон, а тогда что?) знает, что наблюдение проводится, причём именно за ним?
А вот что касается задержек — это очень хороший вопрос. Вкратце, в рамках такого подхода нужно мыслить немного другими категориями. Об этом я постараюсь рассказать в статье о проектировании программ через конвейерные потоки.
Пожалуйста уточните, что ещё нужно, я обязательно добавлю.
Надеюсь Вы извините меня за мой велосипед и как попытку сделать достаточно лёгкое и универсальное решение с минимумом зависимостей.
Например, GUI в параллели с которым идёт обработка.
Скажем, в моей области (управление технологическими процессами) с применением GUI. GUI — как правило, главный поток, кроме него есть поток, который «принимает решения» по генеральному управлению линией, а также потоки журнала, потоки обмена с контроллерами узлов линии, потоки обмена для синхронизации по сети. Всего порядка 10-12 штук, которые активно взаимодействуют друг с другом посредством асинхронных сообщений. Например, поток журнала, с которым взаимодействуют все. Или поток сетевой синхронизации, который делает запросы в журнал не только для чтения/записи, но и для запросом на кэширование определённых записей в целях ускорения инкрементальной синхронизации журналов по сети.
Или «принимающий решения» поток активно взаимодействует с GUI, но при этом не может позволить в нём постоянные локи — очень нехорошо отражается на взаимодействии с пользователем.
Страшно представить, сколько бы понадобилось отлаживать без асинхронных сообщений.
Или вот пример попроще. Веб-сервер, который на каждый тип задания или пользователя рождает Worker. А сам Worker — конвейерный поток, который отвечает на запросы и выполняет полезную работу. Без необходимости в излишней синхронизации.
По крайней мере, я поставил на повестку дня многопоточные программы без мьютексов и семафоров. Со всеми их плюсами и минусами. Это немного другой подход к многопоточности, который, в идеале, я и стремлюсь обсудить. Надеюсь сделать это в следующей статье, которая будет посвящена исключительно этому, где не придётся размениваться на описание что такое конвейерные потоки.
Но выше хабраюзер crizis показал, что я был не прав, и в таком редиректе нет смысла. С чем, подумав, я и согласился.
Конечно, в этом случае во весь рост встаёт проблема нормализации URL (а она вовсе не тривиальна, как вы понимаете) — но, пожалуй, это меньшее из зол.
Зачем? Во-первых, частично реализованные интерфейсы (иногда экономит массу кода). Во-вторых, по прямому назначению.
Да, это крайне мощный инструмент, а значит им надо уметь очень аккуратно пользоваться.
Это и неудивительно. С++ весь такой.
Кстати, и виртуальным наследованием также пользуюсь. Тоже стараюсь очень аккуратно.
Когда есть смысл заменить наследование на включение объекта в класс, всегда это делаю. Потому что наследование — гораздо более сильная форма сцепления, чем включение в класс. Если кого интересует подробнее, рекомендую внимательно почитать Голуба.
Для многих /простых/ людей, yandex@ya.corp.ru (даже если они туда и посмотрят), выглядит вполне респектабельно. И так будет продолжаться ещё долго, потому что простой пользователь очень далёк от этих «тонкостей». Как бы нам, айтишникам, ни хотелось обратного.
В письме нужно вырезать весь скрипт и формы. Увы. Иначе вот такое никогда не кончится.
А ссылки надо «переписывать» через внутренний редирект, который «обнуляет» куки.
Мой вопрос остаётся прежним: откуда фотон (или не фотон, а тогда что?) знает, что наблюдение проводится, причём именно за ним?