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