Приоритет Linux IO - порядок FIFO? ...или же? - PullRequest
0 голосов
/ 07 сентября 2011

Предположим, что два процесса (или потоки) оба вызывают write в канале / сокете / терминале, чей буфер заполнен, таким образом, блокируется. Есть ли какая-либо гарантия относительно того, кто будет писать первым, когда станет доступно буферное пространство? Это заказ FIFO? Глобально, или в рамках данного уровня приоритета, и упорядочены сначала по приоритету? Или это совершенно случайно / неопределенно?

А как насчет голодных чтений? Будут ли первые, кто позвонит read, получат данные, когда они станут доступны?

Я спрашиваю конкретно о Linux, и, насколько мне известно, POSIX ничего не может сказать об этих проблемах, но мне также было бы интересно, если я ошибаюсь в этом, и POSIX выполняет определенные действия.

Ответы [ 2 ]

5 голосов
/ 07 сентября 2011

В ядре функция pipe_wait() используется как блоком чтения, так и блоком чтения.Эта функция использует макрос DEFINE_WAIT() для определения очереди ожидания, которая устанавливает элемент .flags в очереди ожидания на ноль.

Они просыпаются при вызове wake_up_interruptible_sync_poll(), который вызывает __wake_up_common().Вы можете видеть, что, если элемент .flags не имеет установленного бита WQ_FLAG_EXCLUSIVE (как в этом случае), тогда все официанты бесцеремонно запускаются.

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

2 голосов
/ 07 сентября 2011

Краткий ответ:

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

Дополнительная информация:

Когда данные доступны по каналу / сокету, может возникнуть состояние состязания, при котором, казалось бы, случайный процесс может сначала захватить блокировку. В general процессы с более высоким приоритетом сначала получат блокировку, но это должно зависеть от , а не , поскольку этому могут способствовать многие другие факторы, такие как количество ядер процессора и активное резьб.

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

...