OberonCore

Создаю несколько потоков. В одном из них устанавливается соединение с БД. Приложение постоянно должно обращаться к БД при прибытии пакетов с сервера для их расшифровки. Но через некоторое время мусорщик убивает коннект. Приложение падает. Что делать?

Может нужно помечать те элементы, которые удаляет сборщик мусора, тэгом [untagged] или подобными?

Ира, покажите, пожалуйста, пример кода. А то с налету понять, в чем там проблема, сложно. Если коннект на БД хранится в модуле глобально, то сборщик мусора его прибивать не должен, и тут многопоточность ничего не меняет. А как именно делаете Вы?

Вообще с многопоточностью в ББ надо очень осторожно.
Никаких NEW. Все ссылки должны быть только на глобально привязанные объекты. Ну и масса ограничений на вызов библиотечных процедур.

Для данной задачи лучше обойтись без потоков.

Сложно обойтись без потоков, а без NEW еще сложнее. Каждый поток поочередно обрабатывает прибывающие ежесекундно пакеты данных.
Первый - получает, второй-анализирует заголовок, третий отделяет еще некоторые данные, а четвертый - обновляет изображение в окне.
Каждый поток, переработав пакет, передает его следующему. Для этого он вставляет его в список. А следующий поток берет из списка пакет, обрабатывает и ложит в список для третьего потока и т.д.
Элементы в список добавляются с помощью NEW, тут уж никак не обойтись. Но на это потоки пока не жаловались (но они еще долго и не работали, так как вскоре все виснет вместе с ББ и выход только один - ctrl+alt+del).

Это они так жалуются . По такой схеме точно работать не будет.

Убрала соединение с БД и все работает. Пол часа работало без проблем , только при закрытии окошка ББ тоже закрывается. Но это уже не так страшно. Попробую на ночь оставить.

После ночи работы в тестовом режиме (пакеты с информацией для расшифровки каждую секунду шли с тестовой машины) вывалилась серия окошек с ошибками и инфой:
illegalExecution
Kernel.TrapCleanup
Kernel.TrapHandler
...
HostWindows.UpdateScrollbar
HostWindows.Window.UpdateScrollbars
...
Kernel.Try
HostMenus.ApplWinHandler
А также окна с трапом, после нажатия кнопки ок в вышеописанном окне. Из него следует:
При вызове функции GetSection(w, focus, vertical, size, sect, pos, valid); из HostWindows.UpdateScrollbar значение параметра valid было неопределено и написано что-то в виде un..:97.
Получается кто-то запорол это значение? И с этого момента начинает идти обработка ошибки.

Поскольку Блэкбокс не расчитан на многопоточность, может случаться всё что угодно. Представьте, что в то время когда сборщик мусора занимается чисткой, какой-то другой поток вызвал NEW - поведение не предсказуемо...

Да, NEW в дочерних потоках использовать точно нельзя. Скорее всего, эта операция не имеет повторной входимости. Можно, в принципе, сделать Action, который будет крутиться в основном потоке, получать заказы от боковых на выделение памяти и передавать указатель. С соответствующей синхронизацией, естественно.

Кстати, не стоит отчаиваться.
То что NEW нельзя вызывать из других потоков кроме главного, с одной стороны, конечно, плохо. Но с другой стороны, это хорошо тем, что подсистема управления памятью работает быстрее - ведь ей не приходится тратить время на синхронизацию ! Когда я сравнивал скорость работы подсистем управления памятью в BlackBox и .Net, то были задачи, на которых BlackBox работал в 2-3 раза быстрее .Net. Наверное, отчасти, по этой причине.

А кто будет синхронизировать уборку?

P.S. А что за проблема написать многопоточный GC? BB ведь так легко расширяется? Тем более, что никакие интерфейсы менять не надо. Всего-то подменить модуль kernel на многопоточную версию

Надо будет решать эту задачу. Давно хотим с Борисом взяться, пока нужды особой нет, а "впрок" делать - нет времени.

Для многих прикладных задач, в частности, графики и интерфейса, вполне хватает Services.Actions - есть даже свои плюсы, например, никакой конкурентности, блокировок не надо. Недавно поддержку AniGIF писали - отлично работает, никаких тормозов, хоть весь экран увешать анимашками

Но в целом многопоточность нужна, кто спорит...

Нда... Сборщик мусора не сможет определить, когда память стала не нужна потоку, т.к. у потока свой стек и след-но, сборщик туда не доберется. Кстати, у Иры как раз из-за этого и проблемы - ссылки на объект, хранящиеся в стеке потока, для сборщика не существуют - и он с чистой совестью прибивает объект. Решение на скорую руку - см. выше. Только при выдаче ссылки наш "минименеджер" должен ее запоминать и внутри себя. А переставать хранить эту ссылку 1) когда видит, что запрашивавший память Thread уже мертв. Тогда, если этот Thread ссылку никуда глобально не запулил, объект будет прибит. 2) по явному вызову Dispose - который отпускает объект на милость сборщика. Только передавать между своими потоками ссылки без глобального сохранения при таком варианте нельзя.

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

Для гуя один поток - это вообще правило с очень редкими исключениями. Но как только кроме гуя появляется что-то еще, требующее асинхронности (например, любой I/O с длительным временем реакции - будь то хождение к базе или COM-порт) - без потоков сложно.

ну да, на да. Куда же без них? Сделаем...

Я тоже могу такую умную фразу завернуть: "Program languages are for people who can't program in machine codes".

От модератора:

Алексей и GUEST!
Вашу беседу о параллельном ББ вынес в отдельную ветку:

http://blackbox.metasystems.ru/forum/vi ... .php?t=110

[quote="Ира"][quote="Trurl"]Вообще с многопоточностью в ББ надо очень осторожно.
Никаких NEW. Все ссылки должны быть только на глобально привязанные объекты. Ну и масса ограничений на вызов библиотечных процедур.
Для данной задачи лучше обойтись без потоков.[/quote]
Сложно обойтись без потоков, а без NEW еще сложнее. Каждый поток поочередно обрабатывает прибывающие ежесекундно пакеты данных.
Первый - получает, второй-анализирует заголовок, третий отделяет еще некоторые данные, а четвертый - обновляет изображение в окне.
Каждый поток, переработав пакет, передает его следующему. Для этого он вставляет его в список. А следующий поток берет из списка пакет, обрабатывает и ложит в список для третьего потока и т.д.
Элементы в список добавляются с помощью NEW, тут уж никак не обойтись. Но на это потоки пока не жаловались (но они еще долго и не работали, так как вскоре все виснет вместе с ББ и выход только один - ctrl+alt+del).[/quote]
trurl pravilno govorit. potoki tut sovershenno lishnie. i bez nih sovsem
ne slogno. pochemu naprimer nelzya sdelat tak chtob odin process po ocheredi delal chast raboty vseh potokov? v cycle delat proc1(); proc2()...
chto meshaet takoy prostenkoy kooperativnoy mnogozadachnosti?
pochitayte obzor OS Portos, Contiki...