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

Вы правы, как всегда.

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

Так я и не пишу приложения, которые зависят от UI. Но дело в том, что разработка многопоточного приложения, порядково сложнее однопоточного. Это, конечно, нам студенты сейчас расскажут как по этой тематике лабы ваяли и открыли для себя локеры. И как всё было просто, потом перешли на Яву...

Вопросов масса: например если рабочий поток шлёт неблокирующее сообщение потоку GUI, а тот висит. Вот что будет?

И главное деньги, как пояснить руководству, что это очень сложно?

Так я за это только и ратую. Но есть проблема: многопоточные приложения порядково сложнее однопоточных. Задача дёшево и быстро выпускать программы, которые надёжны и функциональны. И решают проблемы заказчика, а не философствование про что-то там. И главное надёжность. Вот в чём конфликт идеологий.

Допустим у нас есть поток GUI. Он выполняет свои задачи отображения данных. Есть рабочий поток, который управляет взаимодействием с устройством, есть поток чтения из Ethernet, причём чтение вообще блокирующее. Причём из потока GUI нужно управлять логикой выполнения в рабочем потоке. Нужно останавливать работу из потока чтения Ethernet, нужно перезапускать логику алгоритма внутри рабочего потока, но из потока GUI. И переключать чтение на другой канал данных. Нужно что бы поток GUI отображал всегда корректные данные. А если поток GUI принимает решение об управлении устройством? Нельзя? Нужно. Всё должно работать как часы.

И абсолютно потокобезопасно. Если пользователь нажимает кнопку Закрыть, то все потоки корректно завершают свою работу. И всё красиво без малейших задержек.

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

Сам по себе? Это фантастика. GUI поток может только передавать "внутрь" воздействия
пользователя. А если ползатель зажал кнопку и не отпускает, то и передавать нечего. Не
может мышь сразу два воздействия произвести.

Не... не в этом дело. Мир несовершенен. Допустим мы спроектировали наше приложение так, что только из рабочего потока непосредственно взаимодействуем с устройством. Не всё так просто. Иногда нужно срочно разработать тестовый функционал, так что бы он работал из потока GUI напрямую с оборудованием - это заманчиво просто, но не убил поток рабочий. Это сложно.

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

В общем, смысл в чём? Смысл в поиске идеальной архитектуры, это невозможно, ищем компромисс.

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

Чем мы за это платим? За всё нужно платить. В данном случае платим тем, что фундамент приложения заточен сугубо под наши задачи. Заточен в мелочах, причём в управляемых мелочах.

А как компилятор узнаёт в каком потоке код будет исполняться?

Узнай.

Кстати, можно ссылку на проект? В магазине есть, надеюсь?