SystemV семафоры

Я делаю так:

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

Если мне нужны семафоры, я бужу гарда и прошу его сделать семафор. Т.о. гард все время в курсе всех семафорных дел.

ещё вариант забить на systemV и пользовать или позикс или файловые блокировки

POSIX'ные семафор, к сожалению, далеко не везде доступны, так что надо обходиться и без них

cvv:

> файловые блокировки

(если не в tmpfs) в десятки раз тормознутее.

> ...или позикс...

В Linux Threads в Линухе не было толком позикс семафоров.

Я тестировал лично только 2.4 -- systemV семафоры были быстрее всех прочих прочих методов синхронизации (через ядро, конечно).

>cvv:

>> файловые блокировки

>(если не в tmpfs) в десятки раз тормознутее.

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

2cvv:

>...мере мне такое решение больше нравится чем решение с sysV и управляющим демоном

Ну, демон-то не только за семафорами следит...

А скажите: на уровне ядра SystemV и POSIX sem/shm/msg реализованы по-разному?

Решил изначальную проблему следующим образом:
создаю SystemV набор из трёх семафоров, в котором первый служит фактическим семафором, второй - счётчиком числа процессов, использующих данный семафор, а третий - для синхронизации доступа к счётчику числа процессов(чтобы, например, быть уверенным, что, между увеличением значения второго семафора и получением его значения никто его не увеличит, это нужно для установки начального значения первому семафору). Операции со вторым и третьим семафорами делаю с флагом SEM_UNDO.

Правда остаётся такая проблема: если единственный процесс, использующий семафор срубить через kill -9, то набор семафоров останется висеть в системе, но, следующий процесс, использующий этот набор семафоров, установит первому семафору корректное начальное значение, т.к. значение второго семафора 0.

zhuk:

> на уровне ядра SystemV и POSIX sem/shm/msg реализованы по-разному?

Абсолютно!

Мало того, бОльшая часть POSIX кода в linuxthreads была реализована в юзерспейсе, с использованием стандартный сисколов для входа в ядро там, где надо. А SystemV целиком в ядре.

Как в NTPL дело обстоит, я не знаю. Подозреваю, так же: не зря ж в ядро всякие новые штуки типа футексов добавили...

2andreyk :

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

Что-то не понял...

Все операции над SystemV семафорными наборами атомарны. Учитывая, что семафоров в наборе можно сделать много, можно извращаться довольно сложными транзакциями...

Проблема в том, что нельзя атомарно сделать изменение значения семафора функцией semop и установку значения семафора функцией semctl.