" title="Написать письмо">Написать письмо
Донаты на карту ВТБ:
2200 4002 2461 6363

Статистика

Пользователи : 1
Статьи : 2274
Просмотры материалов : 8697717
 
Многопоточность: получилось-5 (15.10.2025). Печать E-mail
2025 - Октябрь
15.10.2025 17:04
Save & Share
Сначала многопоточность успешно была реализована в Qt, потом - в Borland C++ Builder v.6.0. Далее - реализовано её самое сложное подмножество: параллельное программирование с использованием реальных данных большого объёма. Потом содержимое прошлых материалов, с исправлением ошибок, - было объединено. Теперь - успешная реализация параллелизма в Visual Studio, что ещё больше дополнило данные. Это - последняя часть сериала по потокам.



Использовалась Visual Studio 2017 года вместо 2022. Не стояла цель переписать многопоточную программу на Borland C++ Builder - многопоточно в этой среде: экспресс-тестирование, т.к. даже печатать уже становится больно.

Успешно были созданы потоки (как в режиме многопоточности, так и в режиме параллельных вычислений) - стали понятны закономерности:
- аналог неработающей WaitFor от билдера - работающая Join: ждать, пока поток закончит работу;
- мьютексы сильно замедляют работу при параллелизме (хоть и работают корректно: lock и unlock). Настолько, что критические секции даже проверять не стали, - они, однозначно, быстрее мьютексов;
- конструкция мьютекса "lock_guard<mutex>" - убивает параллелизм, заставляя выполнять потоки последовательно (просто на разных ядрах);
- остался неясен вопрос, что быстрее в функции потока: блокировка самих данных в цикле - или всего цикла с данными;
- объект потока создаётся, привязываясь к конкретной функции в первом входном параметре, - очень удобно. Есть другие входные параметры: в тестовом проекте разработчик добавил вторым произвольный класс, а третьим - число. И это число - является входным параметром в функции. Такой способ передачи данных в поток был недоступен как в Qt, так и в билдере - чувствуется дополнительное преимущество: меньше обращений к глобальным переменным, создавая их копию для потока (по RAM, наверно, при больших объёмах данных - будут жуткие системные требования).

Загрузка логических процессоров (реальных потоков ЦП) показала:
- родительский поток, когда выполняет Join запущенных дочерних потоков: в Join точно есть какой-то аналог while (true) - ядро в "ожидании завершения" загружено процентов на 56;
- 3 дочерних ядра грузятся на процентов 70 - что является результатом лучшим, чем у билдера. Однако и исходный код другой, и 12 ядер надо было грузить вместо 3;
- какого-то хрена, грузился дополнительно один из логических процессоров - таким же графиком, как и родительский поток.

Надо изучить подробнее и мьютексы и секции, реализовав часть кода из программы билдера. Но - #скоро или #никогда.
Обновлено ( 15.10.2025 17:37 )
 
 

Последние новости


©2008-2025. All Rights Reserved. Разработчик - " title="Сергей Белов">Сергей Белов. Материалы сайта предоставляются по принципу "как есть". Автор не несет никакой ответственности и не гарантирует отсутствие неправильных сведений и ошибок. Вся ответственность за использование материалов лежит полностью на читателях. Размещение материалов данного сайта на иных сайтах запрещено без указания активной ссылки на данный сайт-первоисточник (ГК РФ: ст.1259 п.1 + ст.1274 п.1-3).

Много статей не имеет срока устаревания. Есть смысл смотреть и 2011, и даже 2008 год. Политика сайта: написать статью, а потом обновлять ее много лет.
Рекламодателям! Перестаньте спамить мне на почту с предложениями о размещении рекламы на этом сайте. Я никогда спамером/рекламщиком не был и не буду!
Top.Mail.Ru