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

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

Мне кажется нельзя считать что вы до конца понимаете концепцию многопоточности (Multithreading/ Concurrency) если вы не понимаете когда (для каких задач) ее можно и/или нужно использовать на однопроцессорной машине, 2-х процессорной, N‑процессорной машине и от чего это зависит.

 Мне давно хотелось узнать существуют ли программисты, которые понимают «делегирование» в рамках ООП так же, как я.  А когда я случайно обнаружил что в Шаблонах проектирования (Design Patterns) в фундаментальных трудах признанных классиков концепций программирования пропущено описание для Делегирования, у меня появился повод написать эту статью.

Так получилось, что я сначала познакомился с этой техникой на практике разрабатывая DirectShow фильтры и COM-объекты, которые составляют эти фильтры и меня особо не интересовало как все это по-умному называется пока это все прекрасно работает. Проблемы возникают, когда ты пытаешься объяснить кому-то КАК это работает, или когда ты пытаешься предложить кому-то хотя бы попробовать использовать определенную технику программирования. Вот именно при таких попытках у меня получилось сопоставить что то, что я использую очень подходит под определение Design Pattern: Delegation.

Давайте посмотрим будет это поводом посмеяться или задуматься.

Должен предупредить что тем, кто воспринимает чужое мнение по техническим вопросам как оскорбление только потому, что он не согласен с этим мнением, не нужно читать эту статью.

Кто дочитает до конца найдет ответ на вопрос который задает название.

 Что надо знать, чтобы успешно применять-реализовать многопоточность (Multithreading) в своей программе? Мне кажется есть некоторые неудобные для изложения куски в разных описаниях потоков и того, что с ними связано, которые остаются не раскрытыми или вообще пропускаются.

Мне хочется предложить на суд читателей мое собственное понимание таких неудобных аспектов, связанных с применением многопоточности для практического программирования, которое накопилось у меня за пару десятилетий успешного применения этой самой многопоточности на всех уровнях разработки от Embedded и аппаратно-ориентированных уровней до C#, WPF, Java высокоуровневых фронт-ендов.

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

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

Кто-то в коментариях нашел очень интересные аналогии для изложенного в статье решения задачи: https://triztrainer.ru/theory/principles/principle13/

По результатам критики, мне очень интересно было узнать что существует:

"Метод инверсии или методика проектирования «от противного», абсурдной перестановки. Такой подход к проектированию основан на развитии гибкости мышления, поэтому он позволяет получить совершенно новые, порой парадоксальные решения."

К написанию статьи меня подтолкнул вот такой вопрос:

Всем добрый день. Хотел бы получить краткие и понятные для новичка ответы на следующие вопросы:

Что такое COM объект?

Как происходит разработка COM объекта?

Какие особенности реализации COM Microsoft?

Прошу воздержаться от скидывания многостраничной литературы. Спасибо.

Ниже предлагаю свой развернутый ответ, который, почему-то, неизменно возбуждает вопрос из нового заголовка статьи. Интересно было получить оценку сообщества профессионалов. Надеюсь и новички смогут найти что то полезное.

Мне последнее время приходится заниматься интерфейсом приложения для анализа данных, визуальным представлением данных на разных слоях анализа, а также навигацией по слоям и по данным. Соответственно, пришлось разбираться c новомодным WPF, который продвигает концепцию реализующую возможность параллельной (независимой) работы дизайнеров, занимающихся внешним видом приложения и разработчиков, реализующих поведение приложения. Дизайнер, конечно, из меня не очень (мягко говоря), а вот с реализованной концепцией программирования внешнего вида элементов управления в приложениях, мне, кажется, удалось разобраться. Собственно, вот этим пониманием некоторых аспектов концепции я и хочу поделиться, в том числе для того, чтобы расширить это понимание по результатам критики и/или обсуждения.

Возможно, кому‑то будет интересно сравнить то, что предлагает WPF, с концепциями реализованными, например, в JavaFX.

Резюме – Принципы OFDM модуляции уже получили большое распространение в аппаратуре связи (к сожалению, в основном зарубежного производства). Они обещают высокую спектральную эффективность и в то же время обладают способностью бороться с частотной селективностью каналов. К сожалению, пик-фактор в таких системах больше, чем в системах с одноканальной модуляцией. Теоретические предпосылки для решения задачи снижения пик-фактора рассматриваются в данной статье. В частности, рассматривается связь пик-фактора элементарного OFDM сигнала с начальным распределением фаз на поднесущих. Мы планируем, что эта статья откроет цикл исследований, посвященный вопросам практической реализации принципов OFDM модуляции.

Когда-то мне довелось делать программу для управления процессом измерения в мониторе артериального давления (АД). Хочу на этом примере разобрать и продемонстрировать что нужно для решения задач реального времени. Наверно на этом примере можно понять, в том числе, когда нужно использовать RTOS.

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

Хочу поделиться своим вариантом способа хранения параметров. Мой вариант подходит не только для хранения в какой-то отдельной энергонезависимой памяти (далее Епром), он изначально придуман для хранения калибровочных значений в остатке флеш памяти программ.

Я рассматривал задачу не только с точки зрения хранения данных, а еще и с точки зрения эффективного использования Епром для их изменения.

RTOS или не RTOS вот в чем вопрос 2, или Windows тоже RTOS?