![]() |
|
|
Регистрация | << Правила форума >> | FAQ | Пользователи | Календарь | Поиск | Сообщения за сегодня | Все разделы прочитаны |
![]() |
|
Опции темы | Поиск в этой теме | Опции просмотра |
#1
|
||||||
|
||||||
![]() Доброго Всем.
Собственно ситуация программа для статистики. Делается выборка из блока данных по определенным правилам. есть тип запись обьедененная в массив обьявляю так: Код:
есть поток в нем обьявляю так Код:
обработка данных в форме Код:
Теперь собственно грабли. Все Вычесления проходят в форме - результат правильный. повторяемость 100% - но ОЧЕНЬ медленно. вычисления проходят в потоке БЕЗ ИЗМЕНЕНИЯ массива OutFDDataSect - результат правильный. повторяемость 100% вычисления проходят в потоке С ИЗМЕНЕНИЯ массива OutFDDataSect - и тут начинаются грабли. правильного результата нет. часто дожодит до зависания потока намертво. при дебаге выяснилось что изменения длинны OutFDDataSect не доходят до потока. Вобщем чтото сделал не правильно, при попытке выяснить с помощь гугля и глубокого курения RTFM где именно результата не дало. Причем такоеже обьявление прекрасно и стабильно работает в паралелльной сортировке массива OutFDDataSect методом инжекции. Вобще буду рад любым подсказкам, желательно с кодом. Ужк начал посматривать в сторону стандартной библиотеки System.Threading (Parallel Programming Library (PPL)) в принципе для моей задачи подходит.... |
#2
|
|||
|
|||
![]() Забыл добавить -
специально удалил все попытки синхронизации. все только ухудшалось. Родитель и хозяин OutFDDataSect - TForm, все изменения В OutFDDataSect делает он. Поток при RESUME только читает из него данные и выставляет флаг FindResult. после чего засыпает и ждет другого запуска на поиск. При изменении OutFDDataSect (TForm) нужно обновить RuleArr в потоке. Вобщем нужен алгоритм параллельного поиска в массиве. |
#3
|
|||||||
|
|||||||
![]() Код:
Цитата:
Код:
![]() Код:
Не понятного больше чем понятного. Ну или ты передаёшь не всю картину происходящего. Некоторые программисты настолько ленивы, что сразу пишут рабочий код. Если вас наказали ни за что - радуйтесь: вы ни в чем не виноваты. |
#4
|
|||
|
|||
![]() Код:
Aristarh Dark из 24 байт делается 3 int64 и xor а после выводятся в 24 байта. работает намного быстрее чем прямой перебор. толи в регистр 24 раза загружать, толи 3 .... Но за код спасибо. более красиво получается. один поток сделан чтобы убедиться что все работает правильно. А уж потом заботливо раскладывать самому себе грабли с делением на потоки. Для меня задача - как обновить динамический массив в потоке. при условии что поток в suspend. получить правильный и стабильный результат - а потом уже исполнять танец на граблях в в виде распараллеливания и деспечера потоков. |
#5
|
|||
|
|||
![]() мдя. мыши плакали, кололись - но упорно продолжали грысть кактус или век живи - век учись. сказад ежик слезая с кактуса....
итак костьль найден. пошговый дамп массива из формы и потока показал что данные доходят правильно. результат в потоке тоже верный. Проблема оказалась в необходимой задержке для остаканивания системы и потока после Resume. после введения sleep(10) все заработало. результат повторяемый и совпадает с первым алгоритмом на 100%. Костыль: Код:
|
#6
|
||||
|
||||
![]() Цитата:
Некоторые программисты настолько ленивы, что сразу пишут рабочий код. Если вас наказали ни за что - радуйтесь: вы ни в чем не виноваты. |
#7
|
|||
|
|||
![]() мдя Или "песнь о Великом человеке"
В детстве Били не любили. Что-бы Билли не побили Просто небыло и дня... итак ответ на собственный вопрос пошговый дамп массива из формы и потока показал что данные доходят правильно. результат в потоке тоже верный. Проблема оказалась в необходимой задержке для остаканивания системы и потока после Resume. после введения sleep(10) все заработало. результат повторяемый правда сильно не стабильный. любой чих приводит к зависанию потока.Так-что пердача массива только для чтения через глобальную переменную - вполне правильный подход. В прцессе поиска среди плагиата созданного из одной статьи обратил внимание на TTask & TParallel.For результат TParallel.For - ну вот наконец-то перенесли аналог из FORTRAN-a - а нет. не туто было.... Нормально запустить не удалось. точнее заработало но так медленно что линейный алгоритм сильно обгонял. TTask - заработало. код ниже. паралельность - только в таком виде работает. Сильно зависит от загрузки системы... ускорение от 2 до 2.8 раз. Вобщем если нет желания заморачиватся с диспечером - можно использовать. для проверки основного алгоритма сойдет. для нормальной работы софта - в принципе тоже. Резюме по PPL Lib. Ни о какой паралельности не и речи. Распределенные вычесления - да.(каждому потоку своя копия данных). Работа с общим блоком - только последовательно.... Вся прелесть паралельности теряется на копировании данных в поток... Вобщем что этой библиотекой хотели сказать индусы так и осталось тайной, покрытой матом. Отдельное Спасибо MBo за пример с потоками. По факту - раскуриваю книжку и буду разбиратся с примером. хотелосьбы получить стабильное ускорение процесса от 2.9 и выше. Собственно рабочий код с TTask Код:
|
#8
|
||||
|
||||
![]() Собственно решение найдено, но не все решено.
Огромное спасибо Всем за корректный пинок, на тему - кашу в голове нужно перемешивать, иначе - пригорает. Вообщем траблы решены и вполне корректно - без костылей типа Sleep. Правда 1 вопрос остался. Итак то о чем забывают написать в мануалах. Опять-же - это мое понимание. MsgWaitForMultipleObjects - во время ожидания обработка списка MSG не ведется. Если ожидается больше 1 MSG, в обработку передается только одно. какое из них ????? и обязатально application.ProcessMessages; после выхода. иначе обработка списка не начнется. EventStatus := 1; WaitForMultipleObjects - если присвоение и постановка в ожидание происходит меньше какого-то крит. минимума внутри SystemTick - значение не доежает до интерфейсной секции потока. Решения не нашел. костль тапа sleep ломается. Код рабочий. Потоки контролируемые. ожидание не морозит форму. Лишнего процессорного времени не требует. Кому надо можно поставить потоки - каждому потоку по своему ядру. Проверен на 10 потоках в течении 12 часов. Ошибок не было. Наверно мало гонял. ))) По факту - написать оказалось проще и быстрее. даже с учетом граблей. больше времени ушло на понимание что-же авторы мануалов пытальсь сказать. Особенно в своих примерах. Осталось прикрутить Break потоков на выполнение дурной работы. Будут вопросы по коду - задавайте. Смогу отвечу. Собственно код - на форме 1 кнопка и мемо. названия стандартные. FunTime - LIB для замера времени. можно выкинуть. форма Код:
Код:
|