Multithreading и STL контейнеры

Интересно. Использование clear() на std::vector (даже без данных и без reserve() ) убивает производительность многопоточной задачи в ноль. Т.е. один working thread, последовательно выполняющий некоторое действие, завершает пул задач быстрее в разы, чем при использовании нескольких нитей. По крайней мере в debug версии x64 приложения собранной компилятором Visual Studio. Можно как-нибудь поэкспериментировать с MinGW64, там две версии реализации потоков, враппер к API от MS и posix.

А вот std::tuple такой особенности не имеет, если из треда нужно периодически возвращать что-то с фиксированный размером контейнера, пусть будет std::tuple<long, long, int> . В моем случае это нужно для возвращения прогресса операции в main (GUI) поток с помощью ивентов. Т.е. текущей итерации цикла, максимального значения и процента выполнения. Естественно это все работает не на каждой итерации (которых может быть миллион), чтобы не спамить обработчик событий, а на заданный процент. Так вот в случае std::tuple как контейнера некоторых данных масштабирование задач на физическое количество ядер процессора(потоков) практически линейное, до количества ядер/потоков - 1. Очевидно это (-1 поток от максимального) связано с задачами операционной системы и главного потока приложения.

#Multithreading #C++ #STL