Как условия состязания влияют на чтения и записи (которые происходят одновременно),
Tcpdump имеет опцию -B установить размер накопительного буфера. Значение затем передается libpcap (библиотека, пользовавшаяся tcpdump, чтобы сделать получение действительного пакета) через pcap_set_buffer_size() функция. Страница справочника Tcpdump не указывает, в каких единицах размер буфера указан с-B, но из источника, кажется, что это - кибибайт.
страница руководства pcap_set_buffer_size() не указывает размер буфера по умолчанию (который используется, если эта функция не вызвана), но снова, из libpcap источника, это, кажется, 2 мебибайт, по крайней мере, на Linux (но скорее всего системно-зависимо).
Относительно пакетной буферизации и отбрасывания, необходимо также обратить внимание на установку snaplen (-s) параметр соответственно. man tcpdump:
-s Snarf snaplen bytes of data from each packet rather than the
default of 65535 bytes. Packets truncated because of a limited snapshot
are indicated in the output with ``[|proto]'', where proto is the name of
the protocol level at which the truncation has occurred. Note that taking
larger snapshots both increases the amount of time it takes to
process packets and, effectively, decreases the amount of packet buffering.
This may cause packets to be lost. You should limit snaplen to the
smallest number that will capture the protocol information you're
interested in. Setting snaplen to 0 sets it to the default of 65535, for
back-wards compatibility with recent older versions of tcpdump.
Это означает, что с фиксированным размером буфера, можно увеличить число пакетов, которые вписываются в буфер (и таким образом не отбрасываемый) путем уменьшения snaplen размера.
Два процесса могут иметь тот же дескриптор файла, открытый для записи. Точно так же, как с чем-либо, последние выполняют победы.
Когда процесс открывает дескриптор файла, затем некоторый другой процесс пишет 80 строк в него, буфер памяти первого процесса не будет иметь тех 80 строк. Если это затем запишет буфер в дескриптор файла, то содержание файла будет только, что было во втором буфере памяти.
Теперь, это сказанное много программ в эти дни обнаружит, что исходное содержание файла изменилось, так как это было в последний раз открыто. Некоторые откажутся писать, некоторые предложат Вам перезагружать буфер. Некоторые могут сделать что-то еще. Это до каждой программы, чтобы удостовериться, что это делает правильную вещь. Ядро/файловая система не заботится, и обо всем, что оно знает, что буфер памяти, испытывающий недостаток в 80 строках, является правильной копией.
Теперь, если это - что-то значительно более важное как, говорят, база данных, а не просто некоторый текстовый файл или документ в Вашем корневом каталоге затем, намного более вероятно, что захват файла будет использоваться (который также не должен говорить это vim или gedit не используйте блокировки). База данных будет, вероятно, иметь свой собственный внутренний механизм блокировки также.
Общая философия на платформах стиля UNIX должна быть совместной относительно записей дескриптора файла. Блокировка не является механизмом управления безопасностью (это - то, что полномочия/ACL для), это - механизм целостности данных. Две программы, которые хотят записать данные обычно, хотят удостовериться, что данные записаны правильно, таким образом, они приносят пользу обоим для уважения блокировок друг друга. Ядро/файловая система предупредит о блокировках, но все еще позволяет каждому процессу сделать то, что это думает, является лучшим. Однако Linux действительно поддерживает обязательное осуществление блокировки как опцию монтирования (это может также потребовать поддержки файловой системы, но я не уверен в этом).
Можно читать, больше информации о привязывает статью File Locking Википедии.