GrabDuck

Возможности для увеличения быстродействия многопоточных программ

:

Всем добрый день!

Назрел очередной вопрос для тех, кто занимается многопоточными программами: каким образом вы улучшаете показатели быстродействия программы, в случае, если она не оправдала возложенных на нее в этом плане ожиданий?

Опишу проблему подробнее. После перевода проекта под FreeBSD в многопоточный вариант, итоговая скорость работы не понравилась. Логика исходного проекта должна была остаться практически идентичной, и разнести данные по потокам так, чтобы, например, один поток работал только с одной структурой, и больше никуда не лез, не удалось. Соответственно, упор был сделан на "тонкую синхронизацию", - вышло множество блокировок и мьютексов, которые, теоретически, не должны захватываться кем-то надолго. Но теперь есть опасения, что наличие большого количества обращений к мьютексам выигрыш от использования многопоточки свело на нет. Поделитесь, пожалуйста, опытом, на что стоит обратить внимание, и есть ли какие-то еще возможности борьбы за скорость помимо полной переработки логики проекта?

UPDATE

Чтобы не было путаницы, опишу приближенную модель проекта. В рассматриваемой системе было 4 потока в расчете на 4 ядра:

  • 1-й - основной поток, обслуживает новые соединения, обрабатывает прерывания, и выполняет несрочную работу во время простоя;
  • 2-й - поток приема и обработки запросов от пользователей;
  • 3-й и 4-й - потоки выполняющие обработку разных частей трафика.

Все потоки в недетерминированные относительно друг друга моменты времени периодически читают и записывают данные в различные структуры (порядка 10 штук, включают различные счетчики, массивы с индексами), а так же читают и редактируют 4 различных списка. Основной идеей многопоточного варианта программы было отделить пользователей от обработки трафика, чтобы в случае высокой загрузки они не ждали очень долго, а так же увеличить скорость обработки трафика.