Синхронизация файловых потоков, определяемая реализацией. Почему?
Каково было обоснование создания синхронизации потоков входных файлов для конкретной реализации. Разве не кажется очевидным, что поток заполнит свой буфер (частично или полностью) контентом с внешнего устройства? В стандарте C ++ IOStreams и Locales говорится:
Для выходных файлов синхронизация определяется как очистка внутреннего буфера путем записи содержимого буфера в файл, выполняемый вызовом
overflow(), Для входных файлов значение синхронизации не определено стандартом, а зависит от реализации библиотеки IOStreams.
Разве этого недостаточно, чтобы сделать реализацию симметричной и иметь вызов буферов потоков входного файла? underflow()? В чем причина этого решения?
Решение
Запись имеет побочный эффект изменения файла, и множество авторов, участвующих в гонке за запись в один и тот же файл, не являются редкостью. Запись и чтение файла одновременно также является распространенным случаем. Стандарт в основном говорит, что overflow() марки write() системный вызов (в отличие от буферизованного fwrite()) делегировать синхронизацию операционной системе.
Чтение не имеет побочных эффектов для файлов (оно может обновляться, чтобы быть педантичным), несколько читателей не участвуют в гонке друг с другом, поэтому синхронизация не требуется.
Чтение канала или сокета, с другой стороны, имеет побочный эффект изменения содержимого основного буфера. Однако читатели, конкурирующие за чтение из одного канала, TCP или потокового сокета UNIX, не имеют особого смысла. Это может иметь смысл для сокетов дейтаграмм, но я не уверен, предназначены ли потоки IOS, являющиеся потоками, для работы с сокетами дейтаграмм. Я полагаю, что стандартные авторы не смогли придумать хороший вариант использования для синхронизации чтения и, следовательно, оставили его неуказанным.
Другие решения
Других решений пока нет …