vaibhavbvp Ответов: 2

Выбор между потоком и процессом, который был бы предпочтительным

Я столкнулся с проблемой, когда мы должны принять решение между нижеперечисленными вариантами:

1.процесс создает некоторое X число рабочих потоков.Эти рабочие потоки будут создавать лог-файл определенной длины.
2.Создайте X количество процессов и создайте файлы журналов определенной длины с помощью этих процессов.

Что было бы лучшим подходом.

Что я уже пробовал:

Данной проблеме на основе среды Windows.

Richard MacCutchan

Почему бы не попробовать и то, и другое, добавить какой-нибудь код, чтобы засечь время всей работы, и посмотреть, что получится?

jeron1

Возможно, некоторые вещи, обсуждаемые в этой теме, могут помочь.
c++ - многопоточность против многопроцессорности[^]

2 Ответов

Рейтинг:
9

CPallini

Если предположить, что вам нужно какое-то параллельное выполнение (по крайней мере, концептуально), то это сильно зависит от взаимодействия между различными задачами. Чем больше требуется взаимодействия, тем больше я бы предложил использовать потоков. С другой стороны, если взаимодействие минимально, я бы предложил использовать разные процессы. Вы знаете, что потоки взаимодействуют более просто и с меньшими накладными расходами, в то время как однопоточные процессы обеспечивают более простую модель выполнения и могут быть, по крайней мере в принципе, более надежными (мои два цента).

Рейтинг:
18

KarstenK

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

Поэтому вам нужно точно настроить количество потоков путем тестирования. Важно: тест с кодом выпуска.

Совет: напишите чистый и повторно используемый код для случая, когда настройка показывает другой подход, чем ожидалось.