Комментарии 7
атомарность означает лишь то, что, имея два процесса, в одном два write() в пересекающуюся область и в другом процессе read(), последний получит данные либо по состоянию «до первого write», либо «после первого write», либо «после второго write».
ps. вы точно не путаете read/write с fread/fwrite (которые буферезируют на уровне процесса)?
ps. вы точно не путаете read/write с fread/fwrite (которые буферезируют на уровне процесса)?
Скорее всего автор имеет в виду ядро < 3.14. Вот выдерка из man 2 write:
Среди… API-интерфейсов есть write () и writev (2). И среди действий, которые для потоков (и процессов) должны быть атомарными, есть обновление смещения в файле. Однако в Linux до версии 3.14 это было не так: если два процесса, которые совместно используют дескриптор открытого файла (см. open (2)), одновременно выполняют write () (или writev (2)), то I/O операции не были атомарными в отношении обновления смещения в файле, в результате чего блоки данных, выводимые двумя процессами, могли (что является непрвильным) перекрываться. Эта проблема была исправлена в Linux 3.14.
По моему скромному мнению либо автор, либо переводчик слегка ошиблись. И путают реальный файл и файловый дескриптор, за которым может скрывать нечто другое.
Функция read/write работает не столько на реальных файлах (правда и на них тоже, хотя там есть fread/fwrite), сколько на неком «нечто», например сокетах или файлах устройств (файлы в папке /dev).
Короткий контр-аргумент: например, если у вас операции на сокете, то о какой записи с последующем чтением тех-же данных может идти речь? То, что записали — ушло в одну сторону; то, что читаете — получаем с другой; это абсолютно разные потоки.
И вообще: ни о каком кэшировании речи в принципе нет: если fread запрашивает у драйвера некий кусок в 4к и потом пользователю выдаёт тот объём, что он запросил (хоть у файла, хоть нет), а потом омжет выдать данные из кэша; то read запрашивает ровно то количество, которое запросил пользователь: 2 байта — так два байта (недавно писал драйвер устройства, представляющегося символьным файлом, и всё это очень плотно исследовал).
Кроме того о какой атомарности может идти речь, если при запросе write вызывается одна функция внутри драйвера, а при запросе read — другая. Как это сделано — атомарно или не очень — это на совести программиста устройства/поставщика файла. POSIX тут совсем сбоку.
И да, поддержка адекватного смещения на файле-устройстве может быть очень проблематичной: попробуйте почитать из сокета этак 10-100-1000 Гигабайт, а потом сдвинуть позицию на начало и почитать снова? Ваша ОС будет всё кэшировать? Сомневаюсь. В общем, смещение тоже может не работать от слова совсем.
Функция read/write работает не столько на реальных файлах (правда и на них тоже, хотя там есть fread/fwrite), сколько на неком «нечто», например сокетах или файлах устройств (файлы в папке /dev).
Короткий контр-аргумент: например, если у вас операции на сокете, то о какой записи с последующем чтением тех-же данных может идти речь? То, что записали — ушло в одну сторону; то, что читаете — получаем с другой; это абсолютно разные потоки.
И вообще: ни о каком кэшировании речи в принципе нет: если fread запрашивает у драйвера некий кусок в 4к и потом пользователю выдаёт тот объём, что он запросил (хоть у файла, хоть нет), а потом омжет выдать данные из кэша; то read запрашивает ровно то количество, которое запросил пользователь: 2 байта — так два байта (недавно писал драйвер устройства, представляющегося символьным файлом, и всё это очень плотно исследовал).
Кроме того о какой атомарности может идти речь, если при запросе write вызывается одна функция внутри драйвера, а при запросе read — другая. Как это сделано — атомарно или не очень — это на совести программиста устройства/поставщика файла. POSIX тут совсем сбоку.
И да, поддержка адекватного смещения на файле-устройстве может быть очень проблематичной: попробуйте почитать из сокета этак 10-100-1000 Гигабайт, а потом сдвинуть позицию на начало и почитать снова? Ваша ОС будет всё кэшировать? Сомневаюсь. В общем, смещение тоже может не работать от слова совсем.
Какой-то разброд и шатания…
Прежде, какая-то очень вольная и даже неправильная трактовка стандарта.
В стандарте говорится о поведении «read» произошедших ПОСЛЕ вызова write, т.е. о сериализации доступа, причём, в одну сторону — чтение после записи. О поведении read начатых ДО или ОДНОВРЕМЕННО в wirte там не говорится. Т.е. никакой атомарности в стандарте нет.
А разница в таком определении очень большая, так как полноценная атомарность не нужна и при реализации можно оптимизировать блокировки — блокировать write, выполняемый одновременно с read не нужно.
Во-вторых, атомарность read/write вполне себе достижима блокировками диапазонов страниц в файле. Работа с файлом всё равно производится страницами и нет проблемы выполнять «тяжёлую» синхронизацию только в случае если обнаружена чтения записи в перекрывающиеся на уровне страниц регионы, в которые производится запись. В остальных случаях достаточно легковесной синхронизации, которая там всё равно есть. И блокировка по диапазонам там всё равно есть, так как иначе не получится сделать потокобезопасный кэш. Более того, рассуждения о mmap и прочем это как раз аргументы в пользу того, что контроль по диапазонам всё равно есть и и используется.
Короче, в статье автор говорит об атомарности там, где её никто и не обещал, да, ещё и делает какие-то далеко идущие выводы без понимания того, как реализовано кэширование и работа с файлами в ОС.
Прежде, какая-то очень вольная и даже неправильная трактовка стандарта.
В стандарте говорится о поведении «read» произошедших ПОСЛЕ вызова write, т.е. о сериализации доступа, причём, в одну сторону — чтение после записи. О поведении read начатых ДО или ОДНОВРЕМЕННО в wirte там не говорится. Т.е. никакой атомарности в стандарте нет.
А разница в таком определении очень большая, так как полноценная атомарность не нужна и при реализации можно оптимизировать блокировки — блокировать write, выполняемый одновременно с read не нужно.
Во-вторых, атомарность read/write вполне себе достижима блокировками диапазонов страниц в файле. Работа с файлом всё равно производится страницами и нет проблемы выполнять «тяжёлую» синхронизацию только в случае если обнаружена чтения записи в перекрывающиеся на уровне страниц регионы, в которые производится запись. В остальных случаях достаточно легковесной синхронизации, которая там всё равно есть. И блокировка по диапазонам там всё равно есть, так как иначе не получится сделать потокобезопасный кэш. Более того, рассуждения о mmap и прочем это как раз аргументы в пользу того, что контроль по диапазонам всё равно есть и и используется.
Короче, в статье автор говорит об атомарности там, где её никто и не обещал, да, ещё и делает какие-то далеко идущие выводы без понимания того, как реализовано кэширование и работа с файлами в ОС.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Заметки о Unix: системный вызов write(), на самом деле, не такой уж и атомарный