Зачем нужно устранять низкоуровневую блокировку? У вас есть проблемы с тупиком? У вас есть проблемы с производительностью? Или проблемы с масштабированием? Являются ли блокировки обычно оспариваемыми или не оспариваемыми?
Какую среду вы используете? Например, ответы на C++ будут отличаться от ответов на Java. Например. неоспариваемые блоки синхронизации в Java 6 на самом деле относительно дешевы с точки зрения производительности, поэтому простое обновление JRE может решить любую проблему, которую вы пытаетесь решить. Аналогичные улучшения производительности могут быть доступны в C++ при переключении на другой компилятор или библиотеку блокировки.
В общем, есть несколько стратегий, позволяющих уменьшить количество приобретаемых вами мьютексов.
Во-первых, все, к чему когда-либо обращались только из одного потока, не нуждается во мьютексе.
Во-вторых, все неизменяемое безопасно, если оно «безопасно опубликовано» (то есть создано таким образом, что частично сконструированный объект никогда не виден другому потоку).
В-третьих, большинство платформ теперь поддерживают атомарную запись, что может помочь, когда требуется защитить только один примитивный тип (включая указатель). Они работают очень похоже на оптимистическую блокировку в базе данных. Вы также можете использовать атомарную запись для создания алгоритмов без блокировок для замены более сложных типов, включая реализации Map. Однако, если вы не очень-очень хороши, вам гораздо лучше позаимствовать чью-нибудь отлаженную реализацию (пакет java.util.concurrent содержит множество хороших примеров) — общеизвестно, что при написании собственных алгоритмов легко случайно внести ошибки.
В-четвертых, может помочь расширение области действия мьютекса — либо просто держать мьютекс открытым дольше, чем постоянно блокировать и разблокировать его, либо блокировать «больший» элемент — например, объект, а не одно из его свойств. . Однако делать это нужно крайне осторожно; вы можете легко ввести проблемы таким образом.
person
Bill Michell
schedule
24.09.2008
