В старых нет ничего плохого.Хороший способ сохранить гибкость - разделить проблемы.Обычные (старые стили) структуры данных связаны с тем, как хранятся данные.Блокировка - это совершенно другая задача, которая не должна быть частью структуры данных.
Блокировка - это потенциально дорогостоящая операция, поэтому, если вы можете, вам следует заблокировать несколько структур одновременно, чтобы оптимизировать код.Т.е. блокировка критических разделов не структур данных.Если вы напрямую добавляете блокировку к своим структурам данных, у вас нет возможности оптимизировать этот способ.Также это введет неявные точки синхронизации, которые вы, возможно, не захотите и не сможете контролировать.
Это не отвечает другому аспекту вашего вопроса.Часть «Зачем нам вообще блокировка».Ответ в том, что иногда это просто невозможно обойти.Вам либо нужно где-то заблокировать, либо полностью полагаться на атомарные операции, либо вообще запретить мутации.
Первый способ не осуществим, как я уже отмечал выше, поскольку вы теряете потенциал для оптимизации и у вас есть неявные точки синхронизации.
Только с использованием атомарных операций в вашей структуре данных (т.е.блокирующие структуры) - все еще открытый вопрос исследования, и это не всегда возможно.Я знаю о некоторых неблокирующих структурах, то есть очередях, списках и т. Д., Но я никогда не слышал о неблокирующем дереве.Кроме того, неблокирующие структуры имеют тенденцию становиться намного более сложными и медленными, поэтому нам все еще нужна какая-то лучшая структура для локальных данных потоков, и мы можем добавить их только в наш зоопарк структуры данных.мое мнение лучший из всех них.Изменчивость часто доставляет больше хлопот, чем стоит.Однако это понятие из функционального программирования и имеет смысл только в такой среде.Однако функциональное программирование рассматривается большинством программистов как эзотерическое понятие.Большинство языков, которые фактически используются в производственной работе, в основном используют нефункциональные концепции (это не означает, что они на самом деле более сложны или более подвержены ошибкам, это просто отражает текущее состояние обучения среди разработчиков).По моему мнению, функциональное программирование станет более распространенным, как только люди начнут замечать, что оно автоматически решает их проблемы с многопоточностью.Некоторые другие языки уже заимствуют из функциональных языков, поэтому, возможно, именно здесь мы найдем следующую эволюцию структур данных.