порог должен быть числовым и не NAN, при печати массива numpy, почему numpy.nan не определен в python3

Изменить: Обновлено Aug 2017 с последними изменениями в поведении ОС.

Во-первых, O_APPEND или эквивалентный FILE_APPEND_DATA в Windows означает, что приращения максимальной длины файла (длина файла ») являются атомарными под параллельными авторами. Это гарантируется POSIX, и Linux, FreeBSD, OS X и Windows реализуют его правильно. Samba также реализует его правильно, NFS до v5 не делает, поскольку ему не хватает возможности форматирования каналов для атомарного добавления. Поэтому, если вы откроете свой файл только с помощью append-only, одновременные записи не будут разрываться друг относительно друга на любой основной ОС , если не задействована NFS.

Это ничего не говорит о том, читает ли когда-либо увидит разрывную запись, и на этом POSIX говорит следующее об атомарности read () и write () для обычных файлов:

Все следующие функции должны быть атомарными относительно друг друга в эффектах, указанных в POSIX.1-2008, когда они работают с обычными файлами или символическими ссылками ... [many functions] ... read () ... write () ... Если два потока каждый вызывает один из эти функции, каждый вызов должен либо увидеть все указанные эффекты другого вызова, либо ни один из них. [Источник]

blockquote>

и

Записи могут быть сериализованы относительно других чтений и записей. Если чтение () данных файла может быть доказано (каким-либо образом) после записи () данных, оно должно отражать эту запись (), даже если вызовы выполняются разными процессами. [Источник]

blockquote>

, но наоборот:

В этом томе POSIX.1-2008 не указано поведение одновременной записи в файл из нескольких процессов. Приложения должны использовать некоторую форму контроля параллелизма. [Источник]

blockquote>

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

Менее безопасным, но все же допускаемым толкованием может быть то, что чтение и запись только сериализации друг с другом между потоками внутри одного и того же процесса, а между процессами записи - сериализован только для чтения (т. е. последовательно выполняется согласование ввода / вывода между потоками в процессе, но между процессами i / o - это только получение-релиз).

Итак, как работают популярные ОС и файловые системы на этом? Как автор предлагаемого Boost.AFIO асинхронной файловой системы и библиотеки файлов i / o C ++, я решил написать эмпирический тестер. Следующие результаты для многих потоков в одном процессе.

---

Нет O_DIRECT / FILE_FLAG_NO_BUFFERING:

Microsoft Windows 10 с NTFS: update atomicity = 1 байт до 10.0 включительно. 10240, от 10.0.14393 не менее 1 Мб, возможно, бесконечно по спецификации POSIX.

Linux 4.2.6 с ext4: update atomicity = 1 байт

FreeBSD 10.2 с ZFS: обновление atomity = не менее 1 Мб, вероятно, бесконечно в соответствии с спецификацией POSIX.

O_DIRECT / FILE_FLAG_NO_BUFFERING:

Microsoft Windows 10 с NTFS: обновление атомарности = до 10.0.10240 до 1096 байты, только если выровнены по странице, иначе 512 байт, если FILE_FLAG_WRITE_THROUGH выключен, а еще 64 байта. Обратите внимание, что эта атомарность, вероятно, является отличительной чертой PCIe DMA, а не разработанной. С 10.0.14393, по крайней мере, 1 Мб, вероятно, бесконечно по спецификации POSIX.

Linux 4.2.6 с ext4: update atomicity = не менее 1 Мб, вероятно, бесконечно по спецификации POSIX. Обратите внимание, что ранее Linuxes с ext4 определенно не превышал 4096 байт, XFS, безусловно, использовала пользовательскую блокировку, но похоже, что последняя Linux окончательно устранила эту проблему в ext4.

FreeBSD 10.2 с ZFS: update atomicity = at менее 1 Мб, вероятно, бесконечно по спецификации POSIX.

---

Итак, во-первых, FreeBSD с ZFS и очень недавние Windows с NTFS соответствует POSIX. Очень недавний Linux с ext4 - это POSIX, соответствующий только O_DIRECT.

Вы можете увидеть исходные результаты эмпирического теста на странице https://github.com/ned14/afio/tree/master/programs/fs-probe . Обратите внимание, что мы тестируем разрывы смещений только на 512 байт-кратных, поэтому не могу сказать, будет ли частичное обновление 512-байтового сектора разрываться во время цикла чтения-изменения-записи.