Как работает shared_mutex?

322

07 марта 2017, 17:02

Не вполне понимаю, как работает shared_mutex в 17-ом стандарте или в boost. Такая ситуация: несколько читателей одновременно захватывают этот мьютекс, при этом постепенно старые читатели его освобождают, а другие читатели его захватывают, т.е., например, захват этого мьютекса из нескольких циклов с разными периодами выполнения. Вопрос: как в таком случае писателю записать данные, защищаемые этим мьютексом? Получается, что этот мьютекс постоянно захвачен каким-то читателем, и писатель не получает его? Или он приоритетней и при попытке захвата он выдвигается на первые позиции в очереди на захват мьютекса? Как решается эта проблема?

Answer 1

Получается, что этот мьютекс постоянно захвачен каким-то читателем, и писатель не получает его?

стоит почитать некоторые детали реализации. На Linux, к примеру, используется POSIX RW-Lock: http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_rwlock_rdlock.html

Собственно по ссылке выше:

The calling thread acquires the read lock if a writer does not hold the lock and there are no writers blocked on the lock.

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

Как это будет реализовано: добро пожаловать в детали реализации. Благо исходники pthreads (точнее NPTL в составе glibc) открыты. На Linux примитивы синхронизации основаны на системном вызове futex.

Есть ещё GNU Pth - это реализация интерфейса POSIX Threads в user-space.

Ну а если будет очень много писанины... То RW-lock не годится. Читатели будут голодать. Этот примитив как раз нужен когда чтения значительно больше, чем записи.