AlekXL
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата: Цитата: Цитата: и если в главном потоке не работает помпа | то главный поток не будет реагировать на сообщения. А других потоков - свои очереди. тут скорее перспектива слезть с windows сомнительна. | Еще в версии для турбы я предпринял несколько шагов, чтобы ускорить запуск приложения. Поскольку у меня тогда был <Pentium 3+384МБ >, я о многопотоке и не думал, а реализовал что-то вроде нитей, привязванных к Application.OnIdle. Задача сканирования ресурсов разбивалась на маленькие порции, которые и выполнялись от идла к идлу, до конца. Потом одну задачу из этого бутстрапа я перетащил в один фоновой поток, поскольку она плохо разбивалась на части, и ГУЙ приложения слегка заикался. То решение было самописное, и грубо реализованное, мой первый опыт многопотока, но - это работало, программа запускалась на 5 секунд, или за 2 две, если запуск был повторный. Ныне, я хочу разделить весь движок на подзадачи, каждую подзадачу выделить в таск, и выполнять их в пуле. Это не необходимость, это - самоцель, повышение квалификации. Я попытался использовать OTL, вернее, запустил демку с параллельной быстрой сортировкой. Задача хорошо паралеллится, и задав размер массива побольше, можно устроит фреймворку "проверку на вшивость". Это проверку OTL тогда не прошла. Сыпала реально страшными ошибками (разрушается логика кучи - хуже проблемы я не знаю), свидетельсвовавшими о проблеме либо в самой библиотеке, либо в демке. Я написал в форуме OTL, но мне этот пшек отписку написал, мол, стек переполняется. Но во-первых стек переполняется не с такими ошибками. Стек вообще сверху, и NO_ACCESS страницей подпирается, а куча где-то ниже. Во вторых демка сыпала ошибками уже на 20-30 миллионах, это очень мало. Короче, я навострился писать свою микро-либу для многопотока. И даже кое-что сделал, та же быстрая сортировка у 100 миллионов уже не вызывала ошибок. Кроме того, очередь тасков у меня была просто TPriorityQueue<T>, из delphi-coll (только пришлось немного ее поправить, чтобы она дефолтила ссылки на удаленые из очереди элементы, иначе инстансы интерфейсов не удалялись вовремя) Однако, мой провокационный тон все же возымел действие. Пшек втихую где-то подшаманил, и через несколько месяцев вышеупомянутый фейл перестал проявлятся в демке. Так что, поразмыслив, я начал внедрять не свой само-пильный пул, а именно ОТЛ. И начало работы это именно бутстрап, еще до создания формы. Для ускорения запуска. Тут как минимум 3 таска: 1) getSettings 2) InitDB 3) InitLocalizer последние два зависят от первого. Так что я погуглил и написал что -то вроде Код: tc1=CreateTask(getSettings); tc2=CreateTask(InitDb); t3:=CreateTask(InitLocalizer); tc1.ChainTo(tc2); tc1.ChainTo(tc3); tc1.Schedule(); | Первое впечатление - неинтуитивно. Цеплять нужно бы из контекста/метода зависимой задачи, к корневой (первой), а не к корневой — зависимые, число и наличие к-х вообще говоря, может быть неопределенным в момент запуска корня. Второе, запуск корневой в OTL должет быть после инициализации зависимых. Это простой, это задержка! И третье, оказывается, к корневой задаче можно подцепить лишь одну зависимую, а не несколько, так что в моем коде tc2 вообще не выполнялся. Если уж сделал такое уродство, так лучше бы выделил функционал ChainTo в свойство, чтобы было понятна сразу единственность. Кроме того, и это в-четвертых, я специально поставил Sleep(20'000); в главном потоке, после процедуры бутстрапа, перед созданием формы, чтобы понаблюдать , запустится ли фон - так вот , он не запустился! Говорят, нужно сделать Application.ProcessMessages чтобы вся это машинерия запустилась, но когда я уже начал пихать этот вызов после бутстрапа, то поймал себя на мысли, что мой код напоминает долб@ный костыль, использование OTL изуродовало мой код, сделав его грязным и неинтуитвным. Так что я беру свой напильник, и возвращаюсь к своей реализации. Там у меня есть и зависимые таски, списком, которые правильно добавляются независимо от того, отработал уже корневной или нет, и дочерние, без выполнения которых родительский таск считается невыполненным, даже если он сам отработал, и блекджек и ш... Кроме того, нет зависимости от Windows Message Queue, который не только непереносим, но его и вообще нельзя контролировать, это черный ящик,и для его использования приходится производить грязные преобразования типов. Неудивительно , что разрушается куча или происходят утечки. | Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 21:06 23-03-2013 | Исправлено: AlekXL, 21:09 23-03-2013 |
|