OberonCore

Вопрос Илье Ермакову:

С какими проблемами можно столкнуться при работе с тредами через WinAPI?
Интересуют не классические проблемы, а специфические для BlackBox.

Заранее спасибо

Уважаемый ilovb, я обязательно отвечу Вам, но чуть позже, может быть, завтра.

Сборщик мусора BB не умеет делать многопоточный Stop-The-World. Соответственно при сборке мусора в одном из потоков могут появиться (с большой вероятностью) висячие ссылки. А потом программа "навернется" в случайном месте.

Потоки могут спокойно работать только в одном случае - если они вообще не работают с динамическими объектами КП.
Т.е. POINTER TO не используется ни прямо, ни косвенно (при вызове каких-то модулей).
Можно использовать POINTER [untagged] и работать с кучей Windows.

В случае нормальном потоки использовать нельзя. Это приведёт к мгновенному сбою, раньше, чем указал Алексей, гарантированно. Во-первых, при маркировке объектов сборщик не учтёт якоря в стеках потоков и просто их соберёт. Во-вторых, всё ещё хуже: когда сборщик маркирует объекты, он делает нечётным их тег типа (значение по смещению -4 от адреса объекта). Таким образом, любой код, который параллельно с маркировкой попробует использовать тег типа какого-нибудь объекта (а это нужно при вызове функций, или при WITH и т.п.), тут же "гавкнется" с ошибкой.

Эти проблемы были решены в Active BlackBox, в нём ядро поддерживает потоки. Он сейчас снят с публикации (как концептуально неперспективный), но препятствий к его использованию, "если припёрло", нет. Могу передать Вам дистрибутив. Но оно под 1.5.

Спасибо за ответ.
Active BlackBox у меня есть.

Илья, а Active BlackBox использует stop-the-world подходи или пользуется какой то другой техникой?
И если это stop-the-world, то как собираются якоря из стектов потоков?

Да, сборщик замораживает все потоки.

Потоки нельзя создавать с помощью WinApi. Нужно использовать функцию создания потока, которая введена в модуль Kernel. Тогда ядро будет знать про поток и корректно обрабатывать его стек при сборке мусора.

У Вас АББ с исходниками?

К сожалению у меня его нет.

Пардон, не заметил, что вопрос от Вас, а не от автора темы. Если нужно, можно организовать.

Как-то уже забылось, не могли бы напомнить, в чем именно заключается неперспективность?

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

В общем, не нравится он мне. Авторское право Но если кто-то хочет использовать, с пониманием, что это просто частное техническое решение, то я, конечно, не против.

Просто виноград зелёный. Не поспел ещё. Кислый наверное.

Недавно дали программку на Дельфи. Там основная нить работает с интерфейсом, как обычно, а параллельная нить - с COM-портом работает в блокирующем режиме. Обмен данными - через группу глобальных переменных. Достаточно чистый и понятный код в результате.

???

В каком смысле?

Нет, я не против потоков, как системного средства.

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

В Оберонах есть ряд паттернов, базирующихся на таком состоянии (и у меня есть ещё ряд своих решений на этом же). Например, DevCommanders.par или Views.Deposit - такого рода "буферы" для взаимодействия компонентов. Кто-то скажет, что это маскирует "негибкость" способов передать и вернуть параметры и т.п., но нафиг мне гибкость, если она тянет за собой сложность системы типов и т.п. Лучше я буду знать, что в рамках одного множества модулей и одной кучи "шурует" только один поток.

Я за такой подход:
- если задачи сильно независимы, то отдельными процессами;
- иначе грузить в одно адресное пространство несколько Оберон-сред, по числу необходимых потоков. Обмениваться между ними нетипизированными двоичными данными.

Тогда нужен механизм удобного оперирования этими Оберон-средами. Ядро, которое умеет запускать ядра?
вариант с запуском N приложений я не рассматриваю, он какой-то варварский

Желательно не только запустить несколько ядер, но и организовать абстрагированные от реализации каналы обмена двоичными данными.
Тогда можно реализовать несколько режимов:
- с разными процессами и каналами на основе memory mapped files (легко реализовать, но не очень эффективно)
- с несколькими ядрами в разных потоках одного процесса и каналами в untagged куче (сложно, эффективно)
- с несколькими процессами и каналами на основе IP (можно организовывать кластера )
а также их комбинации...

Многопоточность не означает что любому потоку разрешено соваться в любое место.

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

> Например, DevCommanders.par или Views.Deposit - такого рода "буферы" для взаимодействия компонентов.

В них надо расставить ASSERTы на исполнимость только, например, из главного потока ББ.

Пусть процедура Threading.GetCurrentThreadId() возвращает целое число - номер потока из которого она вызвана (все потоки перенумерованы). Если манипулирование какими-то данными допускается только из потока с номером t1, тогда в начало соответствующих процедур вставьте такой код: Аналог этой проверки на C#: Код "if (System.Threading.Thread.CurrentThread.ManagedThreadId != this.threadId)" выполняется тактов за пять. То есть практически бесплатно можно осуществлять (динамический) контроль потокобезопасности в объектных подпространствах.

Именно так и делается

Где делается?