The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
синхронизация с быстрым мьютексом, !*! ghost_in_machine, 07-Апр-10, 05:29  [смотреть все]
Здравствуйте!
Вопрос о многопоточном приложении. Задача параллелиться путем разделения на очень много очень мелких подзадач (200-1000 умножений/суммирований), которые выплняються практически независимо. Для синхронизации есть ячейка памяти типа int, с которой надо значение считать (id фрагмента для обработки) и увеличить на 1 (пока меньше некоторого значения). Сначала использовал для синхронизации доступа семафор и все работало. Но реально скорость росла до 6 процессоров (SMP), дальше выполнение замедлялось, вероятно из-за малости параллельных фрагментов для обработки (нельзя увеличить) и дороговизны синхронизации семафорами. Потому я переписал на синхронизацию мьютексом (ядро 2.6, мьютексы быстрые). Теперь код «проскакивает» значения т.е. не останавливаеться при достижении заданого количества счетчика фрагментов. Может, это конечно проблемы с отладкой, но все работает с семафорами, и при замедлении (пересчитать все 10 раз), и в 1-потоковом режиме. Вот я и подумал, может это процессор не успевает перенести из кеша в память новое значение счетчика, пока его считает второй процессор (ведь мьютекс защищает только на время считывания и арифметики первого CPU)? Вопрос, может ли такое быть и, если да, то как с этим максимально эффективно бороться в Linux.
Спасибо.
  • синхронизация с быстрым мьютексом, !*! ACCA, 06:07 , 07-Апр-10 (1)
  • синхронизация с быстрым мьютексом, !*! svn, 10:48 , 07-Апр-10 (2)
    • синхронизация с быстрым мьютексом, !*! Kane, 10:53 , 08-Апр-10 (3)
      • синхронизация с быстрым мьютексом, !*! svn, 12:27 , 08-Апр-10 (4)
        • синхронизация с быстрым мьютексом, !*! ghost_in_machine, 03:08 , 09-Апр-10 (5)
          Всем спасибо, ошибка нашлась в коде (были гонки с main потоком по включению/засыпанию расчетных потоков при переходе к параллельным вычислениям и назад).
          Да, о pthread_mutex в NPTL я и говорил (честно говоря с чистыми фьютексами чувствую себя некомфортно и как-то запутанно).  
          П.С. Если кому интересно подобный опыт, то код с скмафорами на 16-ядерном SMP Xeon E7340 @2.4GHz, Linux 2.6.9-55 забирал 600-800% по top, а теперь 1550-1570% (почти случайные франменты данных из 30Mb процесса). Это для параллельного расчета подзадач на 200-1000 умножений/суммирований, общий ресурс - из 1 ячейка int считываеться и увеличиваеться на 1. Это я к тому что для числодробилок вообще штатная ситуация когда многие, но весьма маленькие куски можно расчитывать независимо (тратить 1 поток на сборку кусков и подготовку нових пока все остальные их перемалывают) ну и так, если не дергать ядро, можно вполне эффективно распараллелить код  для алгоритма, который вообще-то не параллелиться. Вывод: не зря шумели вокруг фьютексов :).





Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру