Здравствуйте!
Вопрос о многопоточном приложении. Задача параллелиться путем разделения на очень много очень мелких подзадач (200-1000 умножений/суммирований), которые выплняються практически независимо. Для синхронизации есть ячейка памяти типа int, с которой надо значение считать (id фрагмента для обработки) и увеличить на 1 (пока меньше некоторого значения). Сначала использовал для синхронизации доступа семафор и все работало. Но реально скорость росла до 6 процессоров (SMP), дальше выполнение замедлялось, вероятно из-за малости параллельных фрагментов для обработки (нельзя увеличить) и дороговизны синхронизации семафорами. Потому я переписал на синхронизацию мьютексом (ядро 2.6, мьютексы быстрые). Теперь код «проскакивает» значения т.е. не останавливаеться при достижении заданого количества счетчика фрагментов. Может, это конечно проблемы с отладкой, но все работает с семафорами, и при замедлении (пересчитать все 10 раз), и в 1-потоковом режиме. Вот я и подумал, может это процессор не успевает перенести из кеша в память новое значение счетчика, пока его считает второй процессор (ведь мьютекс защищает только на время считывания и арифметики первого CPU)? Вопрос, может ли такое быть и, если да, то как с этим максимально эффективно бороться в Linux.
Спасибо.

• синхронизация с быстрым мьютексом,ACCA, 06:07 , 07-Апр-10
• синхронизация с быстрым мьютексом,svn, 10:48 , 07-Апр-10
  • синхронизация с быстрым мьютексом,Kane, 10:53 , 08-Апр-10
    • синхронизация с быстрым мьютексом,svn, 12:27 , 08-Апр-10
      • синхронизация с быстрым мьютексом,ghost_in_machine, 03:08 , 09-Апр-10
        • синхронизация с быстрым мьютексом,svn, 16:59 , 09-Апр-10
          • синхронизация с быстрым мьютексом,ghost_in_machine, 04:25 , 10-Апр-10
            • синхронизация с быстрым мьютексом,svn, 09:35 , 12-Апр-10

>Вот я и подумал, может это процессор не успевает перенести из
>кеша в память новое значение счетчика, пока его считает второй процессор
>(ведь мьютекс защищает только на время считывания и арифметики первого CPU)?

У многоядерного камня кэш один на все ядра, у многопроцессорной системы принимаются специальные меры, чтобы кэш был "когерентный" между всеми процессорами. Это одна из причин, почему многоголовые матери такие дорогие. Хотя баг в чипсете возможен, но маловероятен. Что вероятнее - дешёвая мать _вообще без_ когерентного кэша. При таком раскладе попробуй включить режим кэша write-through.

Уточни - что за процессоры, что за чипсет, что за мать. Может кто слышал про грабли именно с ними.

>я переписал на синхронизацию мьютексом (ядро 2.6, мьютексы быстрые).

pthread_mutex?

>«проскакивает» значения т.е. не останавливаеться при достижении заданого количества

Где-то забыл блокировку. Вероятно на проверке этого самого значения.

>>я переписал на синхронизацию мьютексом (ядро 2.6, мьютексы быстрые).
>
>pthread_mutex?
>

видимо используются fast userspace mutexes

int sys_futex (void *futex, int op, int val, const struct timespec *timeout);  

>видимо используются fast userspace mutexes

Его и использует pthread_mutex в NPTL.

Всем спасибо, ошибка нашлась в коде (были гонки с 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 поток на сборку кусков и подготовку нових пока все остальные их перемалывают) ну и так, если не дергать ядро, можно вполне эффективно распараллелить код  для алгоритма, который вообще-то не параллелиться. Вывод: не зря шумели вокруг фьютексов :).

Интереснее было бы узнать какой результат показал на этой задаче OpenMP.
Вполне вероятно что было бы ещё лучше, и меньше вероятность сделать ошибку.

>Интереснее было бы узнать какой результат показал на этой задаче OpenMP.
>Вполне вероятно что было бы ещё лучше, и меньше вероятность сделать ошибку.
>

Ваше сообщение поставило меня в тупик :). Не могли бы Вы тезисно пояснить как некая надстройка может быть быстрее прямого взаимодействия нитей? Тоесть я Вас ни в коем случае не критикую ибо не имею практики с OpenMP, но не могу понять как такое может быть впринципе...

> не могу понять как такое может быть
>впринципе...

Шансы что ты распараллелишь лучше openmp - крайне малы. OpenMP использует пул потоков, который намного эффективнее создания потоков. С ним вероятность сделать ошибку, приводящую к неправильным результатам или падению производительности намного ниже.