Стоит ли внедрять бенафоры в современные ОС?

Когда я был программистом BeOS, я прочитал эта статья Бенуа Шиллингса, описывающая, как создать «бенафор»: метод использования атомарной переменной для обеспечения критической секции, который позволяет избежать необходимости захвата/освобождения мьютекса в обычном случае (без конфликтов).

Я подумал, что это было довольно умно, и кажется, что вы можете проделать тот же трюк на любой платформе, которая поддерживает атомарное приращение/декремент.

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

Кто-нибудь знает, используют ли этот трюк внутри современные API блокировки (например, pthread_mutex_lock()/pthread_mutex_unlock())? И если нет, то почему?


multithreading semaphore atomic mutex
person Jeremy Friesner    schedule 28.10.2009    source источник

Ответы (2)


arrow_upward
1
arrow_downward

То, что описано в вашей статье, сегодня широко используется. Чаще всего он называется "Critical Section", и он состоит из взаимосвязанной переменной, кучи флагов и внутреннего объекта синхронизации (мьютекс, если я правильно помню). Как правило, в сценариях с небольшой конкуренцией критический раздел выполняется полностью в пользовательском режиме, без участия объекта синхронизации ядра. Это гарантирует быстрое выполнение. Когда конкуренция высока, объект ядра используется для ожидания, что освобождает временной квант, обеспечивающий более быструю обработку.

Как правило, в наши дни очень мало смысла в реализации примитивов синхронизации. Операционные системы поставляются с большим разнообразием таких объектов, и они оптимизируются и тестируются в значительно более широком диапазоне сценариев, чем может себе представить один программист. На изобретение, внедрение и тестирование хорошего механизма синхронизации уходят буквально годы. Это не значит, что пытаться бесполезно :)

person Rom    schedule 28.10.2009
comment
Позвольте мне быть конкретным на мгновение. В Linux современная (NPTL) библиотека потоков внутренне опирается на фьютексы, которые и являются именно этой уловкой, сохраняя несогласованный случай в пользовательском пространстве, оставляя ядру обрабатывать спорные случаи. Чтобы процитировать справочную страницу, разработчики должны быть грамотными в сборке и читать исходные коды пользовательской библиотеки futex. Это очень сложно и не прощает ошибок. Так что не стоит заново изобретать велосипед, если у вас нет действительно веских причин. - person tialaramex; 13.03.2010

arrow_upward
0
arrow_downward

AbstractQueuedSynchronizer в Java (и его родственный элемент AbstractQueuedLongSynchronizer) работает аналогично или, по крайней мере, может быть реализовано аналогично. Эти типы составляют основу нескольких примитивов параллелизма в библиотеке Java, таких как ReentrantLock и FutureTask.

Он работает путем использования атомарного целого числа для представления состояния. Блокировка может определять значение 0 как разблокированное и 1 как заблокированное. Любой поток, желающий получить блокировку, пытается изменить состояние блокировки с 0 на 1 с помощью атомарной операции compare-and-set; если попытка не удалась, текущее состояние не равно 0, что означает, что блокировка принадлежит какому-то другому потоку.

AbstractQueuedSynchronizer также облегчает ожидание блокировки и уведомление об состояниях, поддерживая очереди CLH, которые представляют собой связанные списки без блокировок, представляющие строку потоков, ожидающих либо получения блокировки, либо получения уведомление через условие. Такое уведомление перемещает один или все потоки, ожидающие выполнения условия, в начало очереди тех, которые ожидают получения соответствующей блокировки.

Большая часть этого механизма может быть реализована в виде атомарного целого числа, представляющего состояние, а также пары атомарных указателей для каждой очереди ожидания. Фактическое планирование того, какие потоки будут конкурировать за проверку и изменение переменной состояния (через, скажем, AbstractQueuedSynchronizer#tryAcquire(int)) выходит за рамки такой библиотеки и относится к планировщику хост-системы.

person seh    schedule 07.12.2009