А в чем возникали проблемы потоков и GUI? Я в Builder'е что то делал не очень много, но с подобными проблемами не сталкивался.

Нет, это писал не я. Но я прекрасно знаю людей, которые это делали несколько лет назад (сейчас там уже другие). Не скажу за последние модели, но в GSM 100, 110, 120, 130 WMP100 стоит не так давно, сначала сим 300 стоял, и вся программа в пике, максимум что перенесли в WMP это дтмф. Я этот подход не разделяю, и сделал подобную систему полностью на SL6087.

Из частного не следует общего. Большая часть потоков порождена парочкой безумных программ, остальные однопоточные или имеют весьма ограниченное число потоков. Даже службы windows попытались компактно разместить в рамках одного svchosts.exe, а не размазывать по безумному числу процессов или потоков.



Это специфика конкретных библиотек. Вообще для работы с TCP/IP не нужно over9000 потоков, более того, крайне вредно для массового обслуживания: google://C2K problem.
"Тяжёлые" сервера, например, могут создавать множество потоков, но уже не fork под каждое соединение (самое простое и плохое решение), а для последовательной обработки запросов одним потоком из пула свободных. А совсем тяжёлые обходятся одним потоком (процессом) и таки event driven моделью программирования.



Она встречается в любом GUI, кроме самых примитивных может быть. Она встроена в windows, она в X-window тоже (и там вся графика отрабатывается одним потоком, одним процессом). Без событийной модели (сигналы-слоты -- по сути тоже событийная модель) я не представляю как вообще GUI построить. Из GUI toolkits без событий мне вспоминаются только поделки для текстового режима 90-х годов. Но там все окна, элементы -- модальные. Невелика хитрость.

Ещё важный момент событийно-ориентированного программирования -- отсутствие жёсткой связности компонентов на момент компиляции. Компоненты A и B могут работать вместе, но они не знают друг о друге. Т.е., например, функция A() не может напрямую вызвать функцию B(), и наоборот. Это принципиальное свойство и сколько-нибудь большие программы без него сложно построить (иначе невозможно изолировать модули, каждый должен знать о каждом). В примитивной форме такая (не)связность может обеспечиваться callback функциями и установкой в процессе исполнения (не компиляции).



А это говорит, что там нет очереди событий или чего-то в этом роде. А очередь событий здесь -- принципиальна необходима. Или какой-то механизм её замещающий. И тогда ни рекурсий, ни вложенности. Обработка строго последовательная. См. state-machine.com. Но мне у них что не нравится: все задают этот вопрос, а что если очередь переполнится. Такой же механизм, кстати, описан в wikipedia в статье "Embedded system", он же описывается в книгах (обработчики прерываний кладут адреса функций в очередь). Я думаю, ответ здесь должен быть такой, что некоторые события должны обрабатываться непосредственно, без очереди.



Как это не проблема, я же явно указал на принципиальную невозможность использования _переменной_ errno. А после компиляции в бинарный вид оно уже заняло место в конкретных машинных кодах и тут ничего не изменить. Библиотеки расчитывающие на многопоточность (не многозадачность, т.к. к многозадачности с полной изоляцией процессов, а-ля unix, готова любая C-библиотека) изначально имеют что-то вроде #define errno (TLS->errno) и/или даже #define errno (*errno_location()), где функция errno_location() возвращает действительный адрес errno для данного потока.

Если библиотека не предполагает вытеснение -- здесь ничего не сделать. Только использовать её в кооперативной ОС. В таком случае тоже... есть проблемы с рядом функций вроде strtok(), но таких функций действительно по пальцам пересчитать и можно их переписать самому.

А malloc()? Тут очевидно. Не reentrant и не thread-safe.

А printf? Невозможен одновременный доступ к структуре FILE. А ведь на PC из разных потоков всё работает... Не reentrant и не thread-safe.

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



Не надо путать thread-safe и reentrant-safe функции. Это разные понятия, хотя и похожие. Функции для вытесняющей многозадачности должны быть thread-safe.



Это "безопасные" можно по пальцам сосчитать.

И вы туда же: "мы не используем функций C-библиотеки". Вы сами не знаете чего не используете. Потому, что одни функции могут вызываться из других или из функций сторонних библиотек. И вы не знаете какие проблемы связывают C-библиотеку и многозадачность -- вот я о чём. А всё туда же. Не имею ничего против многозадачности, но она возможна только в рамках соответствующей библиотеки и ОС. Я пример привёл: и eCOS и newlib, например, подразумевают многопотчность. А библиотека фирмы dinkumware -- нет, и здесь возможна, максимум, кооперативная ОС, или вообще не возможна. Или можно "не использовать библиотечных функций", но это очень порочный путь.

В мире РС над одним проектом работают десятки, сотни, а иногда и тысячи программистов. Когда у нас подобным запахнет, тогда возможно и задуматься над увеличением объёма памяти и архитектуры...

Какая может быть очередь в однозадачной библиотеке?

Как правильно сами сказали есть как минимум механизм Thread-local storage (TLS) в GCC. Вот там и помещаете errno если используете GCC.

Но я не использую GCC.
В RVCT все гораздо проще. Просто переопределяете функцию __aeabi_errno_addr(). Она вызывается библиотеками C-и на низком уровне для получения адреса errno.
Наверно вы не забываете при создании задач выделять память для переменных задачи с помещением указателя на нее в управляющую структуру задачи.
В любой RTOS эта память из любого места задачи доступна по идентификатору задачи. Вот там и храните errno, пулы памяти для malloc и все прочее что надо.

И вот такими переопределениями низкоуровневых функций весь retargeting и производится. Сами библиотеки при этом остаются в бинарном виде .

Насчет терминологии. Говорю только о RTOS без виртуализации памяти. Поэтому применяю термин многозадачность .

Вопрос в продолжение темы: прошу общих рекомендаций по работе с прерываниями в STM32F1. Особенности, специфика при работе с несколькими прерываниями, на что стоит обратить внимание, грабли, тонкости?

Писали про UART, DMA - рулит, и забыть про прерывания.

Честно говоря никакой особой специфики не заметил. Из общих рекомендаций... ну удобно читать данные из uart в циклический буфер, есть там такая настройка у dma контроллера.
PS в конфе по армам есть целая прикрепленная ветка по STM32


У dma тоже есть прерывания.