Темы или Процессы? Что не зависит от данных задач, что лучше использовать? - PullRequest
3 голосов
/ 16 декабря 2009

Существует множество N независимых от данных задач в режиме реального времени. Каждая из задач обрабатывает некоторый цифровой поток данных. Поток данных для каждой задачи поступает из входного порта, а результирующий поток направляется в выходной порт.

1) Что вычислительно менее интенсивно: задачи в виде процессов или потоков?
2) Зависит ли наилучший выбор от количества доступных физических процессорных ядер?

Заранее спасибо!

Ответы [ 7 ]

3 голосов
/ 16 декабря 2009

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

2 голосов
/ 17 декабря 2009

Если вам на самом деле не нужно делить большое количество состояний между задачами, то процессы, вероятно, будут лучшим вариантом. Более тесная связь между задачами, подразумеваемыми потоками, значительно затруднит предоставление гарантий в реальном времени, а блокирование значительно затруднит проверку поведения в реальном времени.

Короче говоря, процессы должны быть вашей опцией по умолчанию; переключаться на темы, только если вы определили для этого определенную причину.

2 голосов
/ 16 декабря 2009

Нет ни одного ответа на этот вопрос. Просто чтобы привести два примера, Linux имеет тенденцию использовать отдельные процессы совсем немного. Разработчики ядра, похоже, приложили значительные усилия для оптимизации переключения процессов. Потоки были добавлены чуть позже, и, похоже, не получили почти такого же внимания. В результате в Linux отдельные процессы имеют довольно низкую стоимость, и использование потоков вместо этого не экономит огромное количество.

Текущие реализации Windows, напротив, возвращаются к Windows NT. Windows NT базировалась довольно близко на OS / 2, в которой были потоки с самого первого дня. Переключение процессов, похоже, никогда не было оптимизировано до такой степени, как в Linux. Как и следовало ожидать из этого фона, под Windows разница между переключателем процесса и переключателем потока намного больше. Следовательно, вы получаете значительно больше, если пишете код в нескольких потоках, а не в нескольких процессах.

1 голос
/ 17 декабря 2009

Я согласен с ответами, которые говорят, что нет «правильного» ответа. Это очень сильно зависит от требований приложения. Моим личным выбором были бы темы, если нет очевидного выбора.

Но я поинтересовался аспектом эффективности и поэтому написал очень простой глупый тест, прежде чем отправиться домой вчера вечером. «Приложение» просто посчитало количество простых чисел, используя простые проверки деления. Таким образом, это был чисто процессор, связанный без конкуренции за другие общие ресурсы. Таким образом, это действительно только сосредоточено на стоимости переключений контекста. Запуск 64 экземпляров (потоков / процессов) на четырехъядерном Xeon 1,86 ГГц не показал никакой разницы. Каждое задание подсчитывало простые числа до 10 000 000. Общее время составило 333 секунды в обоих случаях.

Когда я ездил на велосипеде домой, мне пришло в голову, что, поскольку не было конфликта за ресурсы, переключение контекста будет минимальным; каждый поток / процесс будет работать на свой полный рабочий день. Поэтому я искусственно принудительно переключал контекст каждые 100 итераций, используя Sleep (0), что, как я считаю, сделал то, что я хотел (Win32). После этого тот же тест занял 343 секунды для версии потока и 350 секунд для версии процесса. Таким образом, версия потока показала ускорение на 1,7%. На самом деле не о чем писать.

1 голос
/ 16 декабря 2009

если ваши рабочие блоки связаны с процессором, лучше использовать процессы, потому что обычно все потоки в процессе работают на одном и том же ядре (по крайней мере, в Linux). использование процесса на ядро ​​ЦП гарантирует, что каждый процесс получит реальное ядро ​​ЦП.

Преимущество потоков в том, что ими очень легко делиться между собой состоянием, поэтому если все, что вам действительно нужно, это загрузить файл без блокировки или отправить запрос в базу данных, то потоки будут лучшим вариантом.

на самом деле, я только сейчас нахожусь в процессе написания чего-то, что вам может пригодиться: менеджера, который порождает несколько рабочих процессов и перезапускает их, если они выходят из / kill / dies. он почти готов, так что вот оно:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>
#include <string>

void termination_handler(int signum)
{
    printf("pid %d : signal %d caught in pid %d\n", getpid(), signum, getpid());
    kill(0, SIGTERM);
    exit(1);
}

int main(int argc ,char** argv) 
{
    if (argc > 1)
    {
        printf("pid %d : Worker code running\n", getpid());
        sleep(10);
    }
    else
    {
        printf("pid %d : manager started\n", getpid());
        // manager
        const int MAX_INSTANCES = 3;
        int numInstances = 0;

        struct sigaction new_action;
        /* Set up the structure to specify the new action. */
        new_action.sa_handler = termination_handler;
        sigemptyset(&new_action.sa_mask);
        new_action.sa_flags = 0;
        sigaction(SIGKILL, &new_action, NULL);
        sigaction(SIGTERM, &new_action, NULL);
        sigaction(SIGINT, &new_action, NULL);

        int status;
        int w;
        do
        {
            while (numInstances < MAX_INSTANCES)
            {
                int pid = fork();
                if (pid < 0)
                {
                    printf("fork failed\n");
                    exit(1);
                }
                else
                {
                    if (pid == 0)
                    {
                        char * const argv1[] = { (char*) argv[0], (char*)"worker",(char *) 0 };
                        char * const envp1[] = { (char *) 0 };
                        std::string prog = argv[0];
                        execve(prog.c_str(), argv1, envp1);
                    }
                    else
                    {
                        numInstances++;
                    }
                }
            }           

            w = waitpid(0, &status, WUNTRACED | WCONTINUED);
            if (w == -1)
            {
                perror("waitpid");
                exit(EXIT_FAILURE);
            }

            if (WIFEXITED(status))
            {
                printf("pid %d : child %d exited, status=%d\n",getpid(), w, WEXITSTATUS(status));
                numInstances--;
            }
            else if (WIFSIGNALED(status))
            {
                printf("pid %d : child %d killed by signal %d\n",getpid(), w, WTERMSIG(status));
                numInstances--;
            }
            else if (WIFSTOPPED(status))
            {
                printf("pid %d : child %d stopped by signal %d\n",getpid(), w, WSTOPSIG(status));
            }
            else if (WIFCONTINUED(status))
            {
                printf("pid %d : child %d continued\n", getpid(), w);
            }
        } 
        while (true);
        //! WIFEXITED(status) && !WIFSIGNALED(status));

        printf("pid %d : manager terminated\n", getpid());
    }
    return 0;
}
0 голосов
/ 16 декабря 2009

1) Что вычислительно менее интенсивно: задачи в виде процессов или потоков?

Обычно интенсивность одинакова. При ОЧЕНЬ экзотических условиях потоки могут быть менее интенсивными.

2) Зависит ли наилучший выбор от количества доступных физических процессорных ядер?

Два или более потоков, работающих на разных ядрах процессора, НАМНОГО БОЛЬШЕ, чем одноядерные системы Это проблемы суперскалярных архитектур.

Процессы - лучший выбор в 99,9%.

Также сложно отлаживать многопоточную среду.

0 голосов
/ 16 декабря 2009

Тема.

Это упрощает многие виды накладных расходов, таких как развертывание. Он более перспективен на будущее, потому что в какой-то момент вы можете захотеть, чтобы они взаимодействовали (например, написать в общий журнал или иметь общую консоль управления).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...