Вопрос:
Насколько сильном можно надеяться на то, что функция flock работает как надо и что значит, если она вернула false? везде ли я могу надеяться на то, что доступ к заблокированному ресурсу будет последовательным?
Лирика:
Иногда мне хочется странного, вот в данных момент захотел написать модуль кэширования и конечно же не простой, а фильтипёрстовый. Для кэширования можно использовать разделяемый файл, но к нему одновременно могут обращаться несколько нитей...
LEVEL UP! Значит нужно делать блокирование файла на время чтения/записи, но если кэш протух, то несколько нитей могут полезь за одними и теми же данными в базу...
LEVEL UP! Значит нужно держать файл под блокировкой пока одна нить ходит за данными, но остальные будут ждать окончания блокировки...
LEVEL UP! Тогда пусть пока одна нить ходит за данными, а остальные нити возвращают старое значение, но что если возвращать нечего или та нить что пошла за данными упала...
LEVEL UP! Использовать спинлок (тут придётся угадывать сколько времени), пока не появится значение или пока не стало понятно что нить упала. Если нить упала, попытаться занять её место или вернуть старое.
Здесь не всё размышление, но суть сводится к тому, что кэш блокируется только на время чтения записи, несколько запросов не ходят за данными одновременно, но и не ждут пока их принесут.
Но это всё лирика, мне важно точно можно ли положить на flock, иначе вся задумка не реализуем.
З.Ы. Подобную стратегию можно использовать и с мемкэшем, но у меня его нет
1. Самогонщик - 28 Ноября, 2012 - 19:01:41 - перейти к сообщению
2. caballero - 28 Ноября, 2012 - 19:13:17 - перейти к сообщению
о базах данных слышал что нибудь?
3. EuGen - 28 Ноября, 2012 - 19:14:02 - перейти к сообщению
?
На Win-системах flock вместо рекомендательной реализует обязательную блокировку. На *nix этого можно достичь, но соответствующая ФС должна быть смонтирована с опцией mand, а так же поддерживать системный вызов fcntl()
Если ФС не поддерживает обязательную блокировку, это значит, что блокировка файла не гарантируется и остается на усмотрение ресурса, пытающегося получить доступ к блокируемому файлу.