Насколько хорош круговой буфер с памятью в Википедии?

Question

Я пытаюсь внедрить круговой буфер в C и столкнулся с примером this в Википедии (удален в июле 2014 года). Похоже, что это обеспечит действительно приятный интерфейс для тех, кто читает из буфера, поскольку чтение, которое обтекает от конца до начала буфера, обрабатывается автоматически. Таким образом, все чтения являются смежными.

Однако я немного не уверен в том, что буду использовать его сразу, поскольку у меня нет большого опыта в сопоставлении памяти или виртуальной памяти, и я не уверен, что полностью понимаю, что он делает.

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

Что было бы действительно здорово, если бы кто-то, у кого больше опыта сопоставления памяти POSIX, мог бы быстро взглянуть на код и сказать мне, действительно ли используемый механизм является эффективным. Правильно ли я думаю, например, что файл в/dev/shm, используемый для общей памяти, всегда остается в ОЗУ или может быть записано на жесткий диск (удар производительности) в какой-то момент? Есть ли какие-то ошибки, о которых я должен знать?

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

Заранее благодарим за ваше время.

Answer 1

Я думаю, что сначала анонимный mmap выполняется только для того, чтобы выбрать какую-либо адресную область в неиспользуемой памяти для хранения обоих сопоставлений.
«/ dev/shm» обычно монтируется с файловой системой «tmpfs», которая хранит все данные в swap/memory. Так что на самом деле это может привести к записи на жесткий диск, но у вас есть те же шансы с вашей памятью malloc.

Даже если мой «/ etc/fstab» говорит, что «glibc 2.2 и выше ожидает, что tmpfs будет установлен на/dev/shm для общей памяти POSIX (shm_open, shm_unlink)». некоторые системы могут не следовать этому. Но я надеюсь, что файлы с отображением памяти работают почти как swap, но они пытаются как можно скорее синхронизировать данные с диском.

Как man mkstemp заявляет - glibc 2.06 и ранее создает файл с разрешением 0666, который может привести к дыре в безопасности, если кто-то поймает ваш файл между mkstemp и unlink.