Производительность потоков Linux в GDB очень быстрая, но в остальном очень низкая

Question

Я работаю над встроенным приложением C ++, работающим в Linux. Недавно я столкнулся с некоторыми действительно странными проблемами с производительностью pthreads.

В моей системе 8 потоков, передающих информацию назад и вперед, защищенных с помощью блокировки мьютекса pthread. При запуске моего приложения в автономном режиме производительность потоков при подключении к блокировке мьютекса крайне низка. Для блокировки и разблокировки мьютекса ~ 200 раз требуется 2,4 секунды на плате ARM с тактовой частотой 500 МГц и больше на моей плате с тактовой частотой 200 МГц.

Странно то, что когда я запускаю свое приложение под GDB, оно запускается очень быстро. Тот же блок кода, который занимал 2,4 секунды автономно, занимает около 2 мс, когда работает GDB.

Я проверил это поведение на двух разных SBC на основе ARM: один под управлением Linux 2.4.26 с gcc 3.4.4 и glibc 2.3.2, а другой под управлением Linux 2.6.21 также с gcc 3.4.4 и glibc 2.3.2.

После обширного тестирования, я подозреваю, что проблема заключается в библиотеке pthreads, которая оказывается одной и той же версией в наборах инструментов обеих плат. Это было бы прискорбно, так как мой поставщик SBC не предлагает очень разнообразных наборов инструментов для своей платы, и я боюсь, что у них всех будет эта проблема. Кто-нибудь имеет представление о том, что может быть причиной низкой производительности, когда не работает под GDB?

Answer 1

Никогда не было проблем с pthreads в ARM, и я подозреваю, что в вашем коде есть проблема гонки или инициализации. Попробуйте уменьшить ваш код до минимального кода, который воспроизводит проблему. Вы должны опубликовать этот код здесь или ту часть, которая, по вашему мнению, является актуальной.

И не забывайте, обычно выбор не нарушен

Используете ли вы LinuxThreads или NPTL (потоки "ядра"?) Если вы используете последний вариант, вы также можете попробовать установить приложение.

Answer 2

Одна идея, на которую вы могли бы взглянуть, это значение счетчика вращений. Это наверняка отличается на ARM вместо системы Intel.

Вы можете попробовать использовать "pthread_mutex_trylock ()" и затем выполнить явную "sched_yield ()", если она не может получить блокировку, возможно, добавьте миллисекундный сон внутри цикла. При этом вы можете прервать операцию блокировки и посмотреть, есть ли какая-либо конкуренция за блокировку.

Могу поспорить, что вам нужно взглянуть на исходный код или хотя бы дизассемблированный pthread_mutex_lock, чтобы исправить это.

Answer 3

Вы уверены, что инициализируете мьютекс так, как вы думаете? Эта вещь находится в переменной области файла или размещена? Я думаю, что GDB в конечном итоге предоставит вам другой набор параметров мьютекса из-за удачи при инициализации памяти.