Предположим, что общий мьютез POSIX уже инициализирован (с использованием PTHREAD_PROCESS_SHARED).Могу ли я переназначить общий мьютез POSIX во время его блокировки?
Затем рассмотрим следующую процедуру:
typedef struct {
pthread_mutex_t mutex;
// ...
} Shared;
Shared *shared = (Shared *)mmap(...); // MAP
pthread_mutex_lock(&shared->mutex); // LOCK
// REMAP
munmap(shared, ...);
shared = (Shared *)mmap(...);
pthread_mutex_unlock(&shared->mutex); // UNLOCK
ли POSIX гарантии, что это будет работать как "наивности" предназначен?
Насколько я вижу, ни одна из соответствующих страниц руководства не упоминает такой сценарий.
Кроме того, что о следующем Linux конкретной альтернативы:
Shared *shared = (Shared *)mmap(...); // MAP
pthread_mutex_lock(&shared->mutex); // LOCK
shared = (Shared *)mremap(shared, ...); // MREMAP_MAYMOVE
pthread_mutex_unlock(&shared->mutex); // UNLOCK
Я могу себе представить, например, реализация PThreads, которая будет хранить указатель на заблокированный мьютекс где-то внутри процесса , Если мьютекс настроен как надежный (PTHREAD_MUTEX_ROBUST), он позволит реализации отмечать мьютекс как «заброшенный», если процесс замирает, когда мьютекс заблокирован.
Я понятия не имею, будет ли такая схема действительно работает, будь то разрешено POSIX, или как мьютекс робастности фактически реализована на любой платформе, но если реализация вдоль этих линий бы работа, и бы быть действительным в соответствии с POSIX, тогда вышеперечисленный сценарий переопределения имел бы неопределенное поведение.
Я не понимаю, почему это не сработает. – Celada
@Celada: Я добавил раздел о том, как я могу видеть, что он может потерпеть неудачу, в зависимости, конечно, от того, какие ограничения POSIX ставят на реализацию. –
Очень хорошая точка про надежные взаимные блокировки. Думаю, ты ответил на свой вопрос! Из-за того, что [поддерживаются glibc в связанном списке] (http://www.kernel.org/doc/Documentation/robust-futexes.txt), я предполагаю, что их адрес памяти не будет внезапно когда они удерживаются. – Celada