Тупик при использовании fork, exec и pipe в параллельной среде

^{Converting comments into an answer.}

Возможно, у вас закончились файловые дескрипторы. При параллелизме 100 итераций цикла, создающего 4 файловых дескриптора на каждой итерации, могут привести к проблемам, если ограничение составляет около 256 дескрипторов. Да, вы закрываете некоторые из них быстро, но достаточно быстро? Это не ясно. И неопределенность планирования легко объясняет различное поведение.

The way I understand openmp is that it goes into the loop body n times at a time where n is the number of threads (am I wrong?). So at any single time I should never have more than n*2 file descriptors which on my machine should be around 24.

Вероятно, это n*4 файловых дескриптора, но могут быть ограничения на параллелизм. Я недостаточно знаком с OpenMP, чтобы авторитетно комментировать это. Существуют ли прагмы, отличные от цикла for, которые следует установить? Мне не ясно, что выполнение показанного кода приводит к параллелизму на Mac, когда код скомпилирован с помощью Clang, который не жалуется на #pragma, в отличие от GCC 9.1.0, который предупреждает о неизвестной прагме при моей компиляции по умолчанию. опции.

Однако с форками и исполнителями, а также с потоками жизнь становится сложной. Файловые дескрипторы не могут быть закрыты, потому что файловые дескрипторы являются ресурсом уровня процесса, поэтому поток 1 может создавать файловые дескрипторы, о которых поток 2 не знает, но которые он разделяет. А затем, когда поток 2 разветвляется, файловые дескрипторы, созданные потоком 1, не закрываются, что не позволяет cat правильно определять EOF и т. д.

Один из способов проверить это — использовать такую ​​функцию:

#include <sys/stat.h>

static void dump_descriptors(int max_fd)
{
    struct stat sb;
    for (int fd = 0; fd <= max_fd; fd++)
        putchar((fstat(fd, &sb) == 0) ? 'o' : '-');
    putchar('\n');
    fflush(stdout);
}

и в дочернем коде назовите его подходящим номером (возможно, 64 — может быть случай использования числа до 404). Хотя заманчиво попробовать использовать flockfile(stdout) и funlockfile(stdout) в функции, это бессмысленно, если она вызывается только в дочернем процессе, потому что дочерний процесс является однопоточным, и, следовательно, другие потоки не будут вмешиваться в процесс. Однако вполне возможно, что разные процессы могут мешать выходу друг друга.

Если вы собираетесь использовать dump_descriptor() из потоков родительского процесса, добавьте flockfile(stdout); перед циклом и funlockfile(stdout); после вызова fflush(). Я не уверен, насколько это повлияет на проблему; он обеспечивает однопоточность через эту функцию, потому что ни один из других потоков не может писать в stdout, пока один поток заблокирован.

Однако, когда я тестировал его с немного измененной версией кода, который выводит PID перед «хорошей» и «плохой» строками и перед выводом dump_descriptors(), я никогда не видел чередования операций. Я получил вывод, как:

14128: ooooooo----------------------------------------------------------
14128: good
14129: ooooooo----------------------------------------------------------
14129: good
14130: ooooooo----------------------------------------------------------
14130: good
…
14225: ooooooo----------------------------------------------------------
14225: good
14226: ooooooo----------------------------------------------------------
14226: good
14227: ooooooo----------------------------------------------------------
14227: good

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

Рассмотрите возможность перенаправления карты дескриптора в файл (или один файл для каждого дочернего элемента) в вашем сценарии, где вы действительно можете получить серьезный параллелизм.

Обратите внимание, что смешивание потоков с fork() по своей сути сложно (как Джон Боллинджеротмеченный) — обычно вы используете один или другой механизм, а не оба.

Когда ваш main завис, введите lsof в отдельном сеансе. Я думаю, вы увидите что-то вроде:

....
cat       5323                 steve  txt       REG              252,0    52080    6553613 /bin/cat
cat       5323                 steve  mem       REG              252,0  1868984   17302005 /lib/x86_64-linux-gnu/libc-2.23.so
cat       5323                 steve  mem       REG              252,0   162632   17301981 /lib/x86_64-linux-gnu/ld-2.23.so
cat       5323                 steve  mem       REG              252,0  1668976   12849924 /usr/lib/locale/locale-archive
cat       5323                 steve    0r     FIFO               0,10      0t0      32079 pipe
cat       5323                 steve    1w     FIFO               0,10      0t0      32080 pipe
cat       5323                 steve    2u      CHR              136,0      0t0          3 /dev/pts/0
cat       5323                 steve    3r     FIFO               0,10      0t0      32889 pipe
cat       5323                 steve    4w     FIFO               0,10      0t0      32889 pipe
cat       5323                 steve    6r     FIFO               0,10      0t0      32890 pipe
cat       5323                 steve    7r     FIFO               0,10      0t0      34359 pipe
cat       5323                 steve    8w     FIFO               0,10      0t0      32890 pipe
cat       5323                 steve   10r     FIFO               0,10      0t0      22504 pipe
cat       5323                 steve   15w     FIFO               0,10      0t0      22504 pipe
cat       5323                 steve   16r     FIFO               0,10      0t0      22505 pipe
cat       5323                 steve   31w     FIFO               0,10      0t0      22505 pipe
cat       5323                 steve   35r     FIFO               0,10      0t0      17257 pipe
cat       5323                 steve   47r     FIFO               0,10      0t0      31304 pipe
cat       5323                 steve   49r     FIFO               0,10      0t0      30264 pipe

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

void *tdispatch(void *p) {
      int to[2], from[2];
      pipe(to);
      pipe(from);
      if (fork() == 0) {
          ...
      } else {
          ...
          pthread_exit(0); 
     }
}
...
for (int i = 0; i < NCPU; i++) {
    pthread_create(..., tdispatch, ...);
}
for (int i = 0; i < NCPU; i++) {
    pthread_join(...);
}

Несколько экземпляров tdispatch могут чередовать вызовы pipe(to), pipe(from) и fork(); таким образом, fd просачиваются в эти разветвленные процессы. Я говорю «утечка», потому что раздвоенный процесс не знает, что они там есть.

Канал продолжает отвечать на системные вызовы read(), пока он либо буферизовал данные, либо для него открыт хотя бы один файловый дескриптор записи.

Предположим, что у процесса 5 открыты два обычных конца двух каналов, указывающие на канал № 10 и канал № 11; а процесс 6 имеет канал №12 и канал №13. Но из-за утечки выше процесс 5 также имеет конец записи канала № 12, а процесс 6 имеет конец записи канала № 10. Процессы 5 и 6 никогда не завершатся, потому что они держат открытыми каналы чтения друг друга.

Решение в значительной степени то, о чем говорили люди в предыдущем фрагменте: потоки и вилки — сложная комбинация. Вам нужно будет сериализовать свои каналы, вилки, начальные закрытые биты, чтобы заставить их работать.

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

Я поделюсь своим объяснением так, как я бы понял сразу. Также поделитесь моим кодовым решением проблемы.

Рассмотрим следующий сценарий: Процесс А открывает канал (это два файла).

Процесс A порождает процесс B для связи с ним с помощью канала. Однако он также создает процесс C, который наследует канал (два файла).

Теперь процесс B будет постоянно вызывать read(2) в канале, что является блокирующим системным вызовом. (будет ждать, пока кто-нибудь не напишет в трубу)

Процесс А завершает запись и закрывает свой конец трубы. Обычно это приводит к сбою системного вызова read(2) в процессе B и выходу программы (это то, что мы хотим).

Однако в нашем случае, поскольку процесс C имеет открытый конец канала для записи, системный вызов read(2) в процессе B не завершится ошибкой и заблокирует ожидание записи из открытого конца записи в процессе C.

Все будет хорошо, когда процесс C просто завершится.

Настоящий тупик возник бы в другом сценарии, когда и B, и C держат трубы друг для друга (как объяснено в ответе Мевета). Каждый из них будет ждать, пока другой закроет свои концы труб. Что никогда не произойдет, вызывая тупик.

Мое решение состояло в том, чтобы закрыть все открытые файлы, которые мне не нужны, сразу после fork(2)

int pid = fork();

if (pid == 0)
{
    int exceptions[2] = {main_to_sub[0], sub_to_main[1]};
    close_all_descriptors(exceptions);
    dup2(main_to_sub[0], STDIN_FILENO);
    dup2(sub_to_main[1], STDOUT_FILENO);

    close(main_to_sub[0]);
    close(sub_to_main[1]);

    char* argv[] = {"cat", NULL};

    execvp("cat", argv);
    exit(1);
}

Вот реализация close_all_descriptors

#include <fcntl.h>
#include <errno.h>

static int
is_within(int fd, int arr[2])
{
    for(int i = 0; i < 2; i++)
    {
        if (fd == arr[i])
        {
            return 1;
        }
    }

    return 0;
}

static int
fd_is_valid(int fd)
{
    return fcntl(fd, F_GETFD) != -1 || errno != EBADF;
}

static void
close_all_descriptors(int exceptions[2])
{
    // getdtablesize returns the max number of files that can be open. It's 1024 on my system
    const int max_fd = getdtablesize();

    // starting at 3 because I don't want to close stdin/out/err
    // let dup2(2) do that
    for (int fd = 3; fd <= max_fd; fd++)
    {
        if (fd_is_valid(fd) && !is_within(fd, exceptions))
        {
            close(fd);
        }
    }
}