посоветуйте максимально быструю rw- блокировку для синхронизации доступа к межпроцесной шаренной памяти

Самые быстрые Semophore System V. Но самые надежные Posix Condition Variables, которые используются в Posix Threads, гарантируют практически равный доступ к разделяемому ресурсу в отличии от первых.

Насколько я знаю, выбора просто нет - только SysV семафоры. POSIX мютексы на futex'ах в рамках glibc такого не поддерживают. Поддерживают ли "сырые" futex'ы ядра - не знаю.

Проверил sem_init - нормально отрабатывает при pshared == 1. Похоже, межпроцессные семафоры на futex'ах уже реализованы (это FC4), тогда они должны быть самыми быстрыми.

большое спасибо за внимание

а какие нибуть соображения на тему:

"Поддерживают ли "сырые" futex'ы ядра - не знаю."

можно высказать?

кто нить с ними вообще имел дело?

У меня кстати первый раз стоит задача с такими жёсткими временными требованиями

лочится будут коефициенты цифрового фильтра (еквалайзера) фильтрующего звук в реальном времени

как ни странно а готового решения надыбать не удалось

А ты точно уверен, что нужны локи? Может достаточно и nonblocking синхронизации, да это немного посложнее, но в твоём случае это будет наиболее оптимальным(насколько я понял твою задачу).

Может быть, пошаманить с lock-free подходами? типа там, копировать таблицу коэффикиентов целиком (если я не все забыл из курса ЦОС - оно маленькое, по крайней мере по сравнению с объемом данных), и атомарно (с memory barrier) обновлять указатель, через который ее читают "чтецы"; а они будут копировать указатель перед обработкой следующего окна. У тебя же есть "гарантированное время устаревания" - т.е. ты точно знаешь, что через какое-то кол-во итераций старая копия тебе не нужна, поэтому можно хранить backlog фиксированной длины.

>(с memory barrier)

Если только smp.

>а какие нибуть соображения на тему:

>"Поддерживают ли "сырые" futex'ы ядра - не знаю."

>можно высказать?

>кто нить с ними вообще имел дело?

Я (лично я) не имел и не советую. Если тебя не устроит быстродействие POSIX семафоров glibc (это "вылизанные" обертки для futex'ов), то тебе дорога в lock-free алгоритмы. Которые чреваты кучей редко проявляющихся, трудно воспроизводимых ошибок. Посмотри здесь: http://www.linux.org.ru/profile/tailgunner/view-message.jsp?msgid=1512101 (но по-моему, обсуждаемое там решение не до конца правильное).

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

Часто ядро линукса страдает от таких ошибок? или winnt? Они не могут себе позволить реализовывать алгоритмы в которых даже 0.1% приводит к ошибке. Так что это какое-то заблуждение, и читать не ту форумную ветку надо, а хотяб какие-нибудь ibm research'и.. или с википедии лучше начать - http://en.wikipedia.org/wiki/Non-blocking_synchronization

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

>Часто ядро линукса страдает от таких ошибок?

Сейчас, когда всё разработано и отлажено - не страдает. Но отладка была тяжкой, понять реализованное - не очень легко (Rusty Russel когда-то написал на эту тему "крик души" (rant)). То, что это сделано кем-то и работает где-то - не повод бросаться реализовывать самому.

> читать не ту форумную ветку надо, а хотяб какие-нибудь ibm research'и.. или с википедии

Статья на эту тему в Википедии полезна только ссылками - остальное просто реклама.

ещё раз всем спасибо. Буду думать

что-то я склоняюсь именно к этому направлению решения задачи