История изменений

Лет дцать (и еще дцать назад) в одном из коммерческих Unix-ов обнаружили печальный факт, что процессы nfsd жрут время почем зря. Как оказалось проблема была в том, что масса нитей получала по select на чтение управление практически одномоментно даже при приходе одного пакета, а потом большинство клацало зубами и становилось снова на select. Потребовалось специальное решение. Т.ч. нормально.

Впрочем аналогичный эффект был и на ДОС ЕС ЭВМ на некоторых видах ожидания, только тот кто обращался к якобы «системному вызову» этого не замечал - возврат был только при получении ресурса - внутри стоял цикл с проверкой получения. Подобных реализаций масса.

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

Лет дцать (и еще дцать назад) в одном из коммерческих Unix-ов обнаружили печальный факт, что процессы nfsd жрут время почем зря. Как оказалось проблема была в том, что масса нитей получала по select на чтение управление практически одномоментно даже при приходе одного пакета, а потом большинство клацало зубами и становилось снова на select. Потребовалось специальное решение. Т.ч. нормально.

Впрочем аналогичный эффект был и на ДОС ЕС ЭВМ на некоторых видах ожидания, только тот кто обращался к якобы «системному вызову» этого не замечал - возврат был только при получении ресурса - внутри стоял цикл. Подобных реализаций масса.

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