Насколько хорош круговой буфер в Википедии? - PullRequest
3 голосов
/ 27 мая 2010

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

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

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

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

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

Заранее спасибо за ваше время.

1 Ответ

4 голосов
/ 27 мая 2010

Я думаю, что сначала анонимный 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.

...