mayton2019

Используй join() для последовательного выполнения потоков.

Тут есть два смысла. Первое - это "проскочить" на собеседовании. Если ты будешь его проходить
на дот-нетчика то полюбому что-нибудь спросят. Может попросят написать какую-то задачу с двумя
потоками где состояние потоков как-то разделяется или события от одного идут к другому.

Из канонических задач на конкуренцию я припоминаю "спящий парикмахер" или официант. Не помню смысл - погугли сам. И задача об "обедающих философах" которая просто моделирует дедлок. И в этой
же задаче дается разьяснение как дедлок убрать.

Из параллелизма есть задача параллельного умножения двух больших матриц. Очень популярная
и многократно обсужденная почти во всех It-ресурсах.

И второй смысл - это просто знать способы распараллеливания медленно работающих задач.

Современные фреймворки - тяготеют к тому чтобы разработчик не встречался с задачей конкуренции.
Яркий пример - акторные фреймворки (Akka, Storm). А в задачах биг-даты - практически все
сводятся к map-reduce и если ты хорошо сделал partitioning для своих таблиц или файлов то тебе вообще
ничего делать не надо. Фреймворк сам позаботится. Добавляй только ему ресурсы (процессоры или ноды).

И любые задачи массовой обработки файлов и сетевых событий - автоматом поднимают проблему мультиптоточки.

Тоесть почитать на эту тему - надо. Но упарываться совсем я-бы не стал. Более того, синтетические
задачи которые приводят в учебниках или форумах часто поражают своей убогостью и ненужностью
постановки. Там просто, споря о постановке можно половину проблем выкинуть или переформатировать
так что и мультипоточка будет не нужна.

Тоесть если будешь решать практические задачи - бери настоящие а не высосанные из пальца.

Вот в один поток на сях. Только сам скомпилируй. 32 млн строк в секунду. Если писать в /dev/null

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

// habr.com : mayton2019 - 3 Sep 2023

char *hex = "0123456789abcdef";
char *buf;

void streamer(int max_depth, int level, char *alphabet, int alphabet_size) {
   for(int i = 0 ; i < alphabet_size ; i++) {
      buf[level] = alphabet[i];   
      if ( level < max_depth ) {
        streamer(max_depth, level+1, alphabet, alphabet_size);
      } else {
        buf[level] = '\0';
        printf("%s\n", buf);
        break;
      }
   }
}

int main(int argc, char** argv) {
  buf = malloc(strlen(hex) + 1);
  streamer(16, 0, hex, strlen(hex));
  free(buf);
  return 0;
}

Вот как я мерял.

gcc hex-gen.c -o hex-gen.exe && ./hex-gen.exe | pv -l -r > /dev/null
[30.7M/s]
[30.1M/s]
[30.3M/s]

Вот если писать в текстовый файл то скорость чуть медленнее. 24 млн строк за секунду.

Вот. Проверяй данные. Что я нигде не ошибся.

UPD: Лишний ноль убрал.
UPD: +break добавил.

Я думаю что проблема автора не имеет окончательного решения в части браузерной оптимизации.

Я какое-то время покупал разные вещицы на аукционах и я заметил что иногда имею дело с ботами-снайперами
которые перебивают мою ставку за 1 секунду до завершения аукциона. Это было в 2012-2013 году. Тогда еще
про ботов мало знали. Но в принципе я догадался что мои конкуренты - это какие-то торговые программы на python e.t.c.

По поводу 10 окон. Я не помню какой там лимит. Кажется для http2/http3 там вообще другие подходы к организации сокетов и сеансов. Поэтому дело может быть не в лимите на сеансы а просто в сетевом трафике.

Я-бы предложил автору во первых провести эксперимент. Поторговать не в 10 окон а в 2 например. Будет-ли разница?

И если сильно-сильно хочется торговать с нулевой реакцией то браузер - здесь вообще не друг. Нужно искать
программиста который напишет торгового бота и не забывать этому программисту доплачивать регулярно
за дорабоки бота (в связи с неизбежной эволюцией сайта). Такова судьба таких приложений.

Еще лучше если торговая площадка сама разработала API и предоставляет его за абон-плату. Это - идеальный
вариант решения проблемы. Тоже требует разработки. Но это right-way.

Посмотри ключик
-fsanitize=thread

и еще посмотри PVS Studio. Вроде у них был статический анализ таких ситуаций но я точно не уверен.
Надо искать инфу.

В данном исходнике нет проблемы атомиков. Но здесь есть проблема отсутсвия синхронизации потоков а и b.
Нужно наладить синхронизацию и дальше атомики станут приносить ощутимую пользу.

Поскольку автор никак не обозначает синхронизацию между ними - то задача выглядит как запуск двух независимых джобов. Это можно сделать в linux/bash например вот так

$ ./app1 &
$ ./app2 &

И потом через команду jobs наблюдать их статус. Работают или нет.

Как сделать поиск максимально производительным? Что использовать? Асинхронность? Многопоточность?

Оптимизация запроса к БД начинается с того что вы выделяете сет активных запросов которые важны для вас.
Для каждого из них строите план исполнения запросов
EXPLAIN [ ANALYZE ] [ VERBOSE ] ......
Потом с этим планом приходите к специалисту (или сюда) и спрашиваете что надо улучшить в
тексте запроса или в таблице или в индексе чтоб было быстрее.

Добавление большего числа исполнительных потоков (сессий БД) обычно не улучшает ситуацию
а только ухудшает. Практика это показывает. Мы быстро выходим на пологую кривую пропускной
способности диска - и дальше хоть добавляй потоки - все будет только хуже.

Насчет асинхронных операций - не знаю. Если мы работаем через пул коннектов - то надо обсудить
построение абстракции асинхронности над абстракцией пула. Это тема отдельного топика.

По Multithreading

"Что выведет следующий фрагмент кода"

Это - самый плохой класс задач на мультипоточку. Я видел много таких. Большинство из них основаны на Race Conditions и бывало и такое что негативный эффект не воспроизводится хотя и ожидается в задаче. А не воспроизводится по тесяче причин. По другой операционке или по другой версии JDK/JRE. Вобщем что
выведет код нужно выкинуть и заменить его на какой-то модульный тест да и еще и под нагрузкой. И беря
во внимание комплексность самого вопроса я-бы не стал такое выводить например в собеседования. Так
можно и мидла макнуть головой в сортир. Попробуйте распознать в коде например задачу обедающих
философов. Я готов спорить на коньяк что если вы никогда не слыхали - то не распознаете подвох.

Где и как подтянуть теорию Multithreading(М). Ответ - нигде. Самый лучший вариант - начать писать много кода
с мультипоточкой и наблюдать. Очень многие эффекты книги не объясняют. И 99% новичек нигде не прочитает
про разницу между использованием synchronized и atomic.

Вобщем берите код с нагрузкой и наблюдайте.

Проверить это можно так. Запускаем jvm-процесс который создает 1000 потоков но не сразу а постепенно. Смотрим в linux top процессов и если количество процессов (потоков) растет то мы получаем доказательство того что jvm-theread линейно связан с числом linux-processes (threads).

В windows ЕМНИП один процесс включает в себя от 1 до бесконечности вычислительных потоков.
В linux процесс и поток отличаются опциями разделения ресурсов. Тоесть что по сути опциями безопасности. Например потоки шарят разделяемую память а процессы - не шарят никогда.

Давайте оценим время для 1 потока. 47К позиций - это надо полагать 47 тыщ SOAP-requests надо сделать. Берем среднее время 400 ms до 3s это будет допустим 1700 ms.

47000 * 1700 ms = 79900s = 1331min = 22hours.

22 часа на 1-поточную загрузку товаров.

Из личного впечатления. SOAP - это не очень быстрый протокол. Хрен его закешируешь на н-жинкс. И я думаю что если его запускать в 2-4-8 потоков то ситуация может усугубиться. Если время прыгает в диапазоне от 400 мс до нескольких секунд то это значит что нагрузка в базе плавает сильно. И владелец этого SOAP-сервиса будет ой как не в востороге от ваших экспериментов. Вряд-ли он предполагал что кто-то будет делать массовые выгрузки.

Самый лучший вариант - предупредить его письменно об этой задаче и о том что вы собираетесь делать. Возможно он сообразит что дело пахнет DDOS-ом и сам предложит вам другой вариант выгрузки.

Непонятно что ты там переименовываешь. CSV файлы - это файлы последовательного доступа. И чтобы изменить 1 строчку и 1 значение тебе надо создать копию файла с изменением. И оригинал убить. В этом кардинальное отличие от баз данных где файлы имеют блочную структуру и изменнеие касается всегоа 1 db-block (обычно кусочек файла кратный 4-8 килобайт).

Вот предлагаю обсудить этот вопрос а уже потом подойти к ... муль-ти-про-цессингу или как ты там написал.

Можно слегка изменить код и скачать сначала четные а потом нечетные тикеры. Может проблема с потоками M1 проскочит мимо. Ну не проскочит - тогда поделить на 4 части. Тикер по модулю 4. Я всегда так делал. Если какая-то инфо-система подавилась данными. Делаем партишенинг.

Рекурсивным поиском в глубину по данной таблице пока не будет исчерпана длина.

Но что-то мне подсказывает что тебе надо сначала сделать однопоточный вариант.

Здесь заложена потенциальная ошибка гонок. Главный и дочерний потоки не синхронизируются через объекты синхронизации. Это означает что если дочерний объект тупанул в фазе например JIT компилляции то главный его не будет ждать и завершит приложение. И мы можем (теоретически) не увидеть даже следов работы дочернего потока. Искусственные паузы sleep() не являются механизмом синхронизации и их не стоит использовать для той цели которую хочет достичь автор. Нужен нормальный join. Или ожидание финала ThreadPool.

У вас - странная терминология. Процессор имеет на борту несколько АЛУ (маркетинговое название Thread).
И вы пытаетесь практическим способом посчитать сколько их?

Это очень опасный пример. Он завязан на фазы уборки мусора. Прогрев JIT. И размер кешей. В зависимости он версий java и ос. И никакой синьор-помидор тут не сможет точно сказать какие переходные процессы текут во 2 варианте кода.

Как переписать - я не знаю. Но мультипоточка всегда полезна при парсинге множества сайтов одновременно. Вот пускай автор сделает веб краулер.

Поскольку речь идет о языке "C" - то надо корректно обрабатывать ошибки open/read/write/fseek/close и реагировать на них. И закрывать файловые хендлы при любом возможном исходе. Ну и не забывать делать free() после malloc(). Грубо говоря количество malloc должно быть всегда равно free.

Если была смерть posix-потока то надо как-то найти все брошеные дескрипторы-сироты и закрыть их тоже. Тоесть процесс-родитель должен как-то их видеть.