| OberonCore https://forum.oberoncore.ru/ |
|
| Многопоточность https://forum.oberoncore.ru/viewtopic.php?f=2&t=104 |
Страница 1 из 1 |
| Автор: | Ира [ Четверг, 19 Январь, 2006 12:46 ] |
| Заголовок сообщения: | Многопоточность |
Создаю несколько потоков. В одном из них устанавливается соединение с БД. Приложение постоянно должно обращаться к БД при прибытии пакетов с сервера для их расшифровки. Но через некоторое время мусорщик убивает коннект. Приложение падает. Что делать? 
|
|
| Автор: | Cardinal [ Четверг, 19 Январь, 2006 14:25 ] |
| Заголовок сообщения: | |
Может нужно помечать те элементы, которые удаляет сборщик мусора, тэгом [untagged] или подобными? |
|
| Автор: | Илья Ермаков [ Четверг, 19 Январь, 2006 17:43 ] |
| Заголовок сообщения: | |
Ира, покажите, пожалуйста, пример кода. А то с налету понять, в чем там проблема, сложно. Если коннект на БД хранится в модуле глобально, то сборщик мусора его прибивать не должен, и тут многопоточность ничего не меняет. А как именно делаете Вы? |
|
| Автор: | Trurl [ Четверг, 19 Январь, 2006 18:03 ] |
| Заголовок сообщения: | |
Вообще с многопоточностью в ББ надо очень осторожно. Никаких NEW. Все ссылки должны быть только на глобально привязанные объекты. Ну и масса ограничений на вызов библиотечных процедур. Для данной задачи лучше обойтись без потоков. |
|
| Автор: | Ира [ Понедельник, 23 Январь, 2006 15:19 ] |
| Заголовок сообщения: | |
Trurl писал(а): Вообще с многопоточностью в ББ надо очень осторожно.
Никаких NEW. Все ссылки должны быть только на глобально привязанные объекты. Ну и масса ограничений на вызов библиотечных процедур. Для данной задачи лучше обойтись без потоков. Сложно обойтись без потоков, а без NEW еще сложнее. Каждый поток поочередно обрабатывает прибывающие ежесекундно пакеты данных. Первый - получает, второй-анализирует заголовок, третий отделяет еще некоторые данные, а четвертый - обновляет изображение в окне. Каждый поток, переработав пакет, передает его следующему. Для этого он вставляет его в список. А следующий поток берет из списка пакет, обрабатывает и ложит в список для третьего потока и т.д. Элементы в список добавляются с помощью NEW, тут уж никак не обойтись. Но на это потоки пока не жаловались (но они еще долго и не работали, так как вскоре все виснет вместе с ББ и выход только один - ctrl+alt+del). |
|
| Автор: | Trurl [ Понедельник, 23 Январь, 2006 17:06 ] |
| Заголовок сообщения: | |
Ира писал(а): Но на это потоки пока не жаловались (но они еще долго и не работали, так как вскоре все виснет вместе с ББ и выход только один - ctrl+alt+del).
Это они так жалуются  . По такой схеме точно работать не будет.
|
|
| Автор: | Ира [ Вторник, 24 Январь, 2006 10:47 ] |
| Заголовок сообщения: | |
Убрала соединение с БД и все работает. Пол часа работало без проблем , только при закрытии окошка ББ тоже закрывается. Но это уже не так страшно. Попробую на ночь оставить.
|
|
| Автор: | Ира [ Пятница, 27 Январь, 2006 10:17 ] |
| Заголовок сообщения: | |
После ночи работы в тестовом режиме (пакеты с информацией для расшифровки каждую секунду шли с тестовой машины) вывалилась серия окошек с ошибками и инфой: 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. Получается кто-то запорол это значение? И с этого момента начинает идти обработка ошибки. |
|
| Автор: | Сергей Губанов [ Пятница, 27 Январь, 2006 10:45 ] |
| Заголовок сообщения: | |
Ира писал(а): ...Получается кто-то запорол это значение?...
Поскольку Блэкбокс не расчитан на многопоточность, может случаться всё что угодно. Представьте, что в то время когда сборщик мусора занимается чисткой, какой-то другой поток вызвал NEW - поведение не предсказуемо... |
|
| Автор: | Илья Ермаков [ Пятница, 27 Январь, 2006 19:28 ] |
| Заголовок сообщения: | |
Да, NEW в дочерних потоках использовать точно нельзя. Скорее всего, эта операция не имеет повторной входимости. Можно, в принципе, сделать Action, который будет крутиться в основном потоке, получать заказы от боковых на выделение памяти и передавать указатель. С соответствующей синхронизацией, естественно. |
|
| Автор: | Сергей Губанов [ Пятница, 27 Январь, 2006 19:49 ] |
| Заголовок сообщения: | |
Кстати, не стоит отчаиваться. То что NEW нельзя вызывать из других потоков кроме главного, с одной стороны, конечно, плохо. Но с другой стороны, это хорошо тем, что подсистема управления памятью работает быстрее - ведь ей не приходится тратить время на синхронизацию  ! Когда я сравнивал скорость работы подсистем управления памятью в BlackBox и .Net, то были задачи, на которых BlackBox работал в 2-3 раза быстрее .Net. Наверное, отчасти, по этой причине.
|
|
| Автор: | Vlad [ Пятница, 27 Январь, 2006 21:01 ] |
| Заголовок сообщения: | |
Илья Ермаков писал(а): Да, NEW в дочерних потоках использовать точно нельзя. Скорее всего, эта операция не имеет повторной входимости. Можно, в принципе, сделать Action, который будет крутиться в основном потоке, получать заказы от боковых на выделение памяти и передавать указатель. С соответствующей синхронизацией, естественно.
А кто будет синхронизировать уборку? P.S. А что за проблема написать многопоточный GC? BB ведь так легко расширяется?  Тем более, что никакие интерфейсы менять не надо. Всего-то подменить модуль kernel на многопоточную версию
|
|
| Автор: | Илья Ермаков [ Пятница, 27 Январь, 2006 23:23 ] |
| Заголовок сообщения: | |
Надо будет решать эту задачу. Давно хотим с Борисом взяться, пока нужды особой нет, а "впрок" делать - нет времени. Для многих прикладных задач, в частности, графики и интерфейса, вполне хватает Services.Actions - есть даже свои плюсы, например, никакой конкурентности, блокировок не надо. Недавно поддержку AniGIF писали - отлично работает, никаких тормозов, хоть весь экран увешать анимашками
Но в целом многопоточность нужна, кто спорит... |
|
| Автор: | Илья Ермаков [ Пятница, 27 Январь, 2006 23:48 ] |
| Заголовок сообщения: | |
Цитата: А кто будет синхронизировать уборку?
Нда... Сборщик мусора не сможет определить, когда память стала не нужна потоку, т.к. у потока свой стек и след-но, сборщик туда не доберется. Кстати, у Иры как раз из-за этого и проблемы - ссылки на объект, хранящиеся в стеке потока, для сборщика не существуют - и он с чистой совестью прибивает объект. Решение на скорую руку - см. выше. Только при выдаче ссылки наш "минименеджер" должен ее запоминать и внутри себя. А переставать хранить эту ссылку 1) когда видит, что запрашивавший память Thread уже мертв. Тогда, если этот Thread ссылку никуда глобально не запулил, объект будет прибит. 2) по явному вызову Dispose - который отпускает объект на милость сборщика. Только передавать между своими потоками ссылки без глобального сохранения при таком варианте нельзя. А в целом, конечно, надо ковырять ядро. В целом надо, на первый взгляд, научить сборщик работать со стеками всех потоков и обеспечить ему повторную входимость критич. секциями. |
|
| Автор: | Vlad [ Суббота, 28 Январь, 2006 01:36 ] |
| Заголовок сообщения: | |
Илья Ермаков писал(а): Для многих прикладных задач, в частности, графики и интерфейса,
Для гуя один поток - это вообще правило с очень редкими исключениями. Но как только кроме гуя появляется что-то еще, требующее асинхронности (например, любой I/O с длительным временем реакции - будь то хождение к базе или COM-порт) - без потоков сложно. |
|
| Автор: | Илья Ермаков [ Суббота, 28 Январь, 2006 03:54 ] |
| Заголовок сообщения: | |
Цитата: Для гуя один поток - это вообще правило с очень редкими исключениями. Но как только кроме гуя появляется что-то еще, требующее асинхронности (например, любой I/O с длительным временем реакции - будь то хождение к базе или COM-порт) - без потоков сложно.
ну да, на да. Куда же без них? Сделаем... |
|
| Автор: | Trurl [ Суббота, 28 Январь, 2006 19:16 ] |
| Заголовок сообщения: | |
Илья Ермаков писал(а): Но в целом многопоточность нужна, кто спорит... Алан Кокс писал(а): A computer is a state machine. Threads are for people who can't program state machines
|
|
| Автор: | Vlad [ Воскресенье, 29 Январь, 2006 06:55 ] |
| Заголовок сообщения: | |
Trurl писал(а): Алан Кокс писал(а): A computer is a state machine. Threads are for people who can't program state machines Я тоже могу такую умную фразу завернуть: "Program languages are for people who can't program in machine codes". |
|
| Автор: | Илья Ермаков [ Понедельник, 06 Февраль, 2006 00:59 ] |
| Заголовок сообщения: | |
От модератора: Алексей и GUEST! Вашу беседу о параллельном ББ вынес в отдельную ветку: http://blackbox.metasystems.ru/forum/vi ... .php?t=110 |
|
| Автор: | CheshireCat [ Понедельник, 28 Август, 2006 06:34 ] |
| Заголовок сообщения: | |
[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... |
|
| Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|