Есть ли приличная оболочка C ++ вокруг lockless SList от Win32?

Question

Windows предоставляет изолированный односвязный список, как описано на этой странице:Win32 SList - Скользящий

Мне интересно, существует ли хорошая оболочка C ++ для этой функциональности.Когда я говорю "хорошо", я имею в виду, что он максимально экспортирует обычный интерфейс STL, поддерживает итераторы и т.д.Я бы предпочел использовать чью-то чужую реализацию, чем садиться писать контейнер типа STL.

Answer 1

Вы могли бы быстро приступить к работе с boost и ::boost::iterator_facade .

Нет, это не было бы оптимальным или переносимым, и семантика итератора - это то, против чего вы должны были услышать, как Александреску внезапно выступил на DevCon.Вы не блокируете контейнер, вы блокируете (и, возможно, повторно блокируете и разблокируете ) операции.А блокировка операции означает последовательное выполнение, очень простое.Существует множество манипуляций с итератором, которые будут ненужным наказанием за создаваемую абстракцию.

С точки зрения Mars, итератор скрывает указатель и прячется под полуо-концепцией, которая столь же вероятна, как и ОО-vs-распределенная разработка..Я бы наверняка использовал "процедурный" интерфейс и заставил пользователей / сопровождающих обратить внимание на то, почему это необходимо.Операции без блокировки хороши только настолько, насколько хорош "весь параллельный код", окружающий их.И классические примеры поскольку люди продолжают переосмысливать обертывание scoped_lock с 96-го года, это создает довольно последовательный код.

Или используйте записи atomic и Sutter's DDJ в качестве ориентира для poor man на будущее (и более 10 лет неупорядоченности Pentium Pro позже).

(все, что действительно происходит, это то, что boost и DDJ выполняются после .net и MS CCR, которые выполняются после неизменяемости, а также intel, которые выполняются после хорошей OO-подобной абстракции для разработки без блокировки.Проблема в том, что это не может быть сделано хорошо, и некоторые люди борются с этим снова и снова;очень похоже на бессмыслицу concurrent_vector из TBB.По той же причине исключения никогда не материализовывались как не вызывающие проблем, особенно в разных средах, и по той же причине, по которой векторная обработка в процессорах недостаточно используется компиляторами C ++ и так далее и тому подобное ..)

Answer 2

Вы никогда не сможете наложить интерфейс в стиле STL поверх SList.Чтобы избежать проблем с управлением памятью, единственным доступным узлом в списке является заголовок списка.И единственный способ получить доступ к этому узлу - удалить его из списка.Это предотвращает появление у двух потоков одного и того же узла, а затем один поток удаляет этот узел, в то время как другой поток все еще использует его.Это то, что я подразумеваю под "проблемами управления памятью", и это распространенная проблема в программировании без блокировок.Вы всегда можете открыть первый узел, а затем следовать указателям "Next" в структурах SLIST_ENTRY, но это чрезвычайно плохая идея, если вы не можете гарантировать, что список не будет сжиматься с освобождением узлов во время его чтения.Конечно, это по-прежнему удаляет головной узел из списка.

По сути, вы пытаетесь неправильно использовать SList.Для того, что, похоже, вы хотите сделать, вам просто нужно использовать контейнер STL и защитить доступ к нему с помощью блокировки.Алгоритмы STL не будут работать со структурами данных без блокировок, которые изменяемы, как SList.

При всем при этом вы могли бы создать оболочку C ++ вокруг SList, но она не была бы совместима с STL.

Answer 3

Стоит отметить, что опубликованный интерфейс на странице, указанной в вопросе, на самом деле не реализует связанный список (хотя это может быть базовая структура) - он реализует стек.Поэтому, если вам нужны функции связанного списка, которые предоставляют такие классы, как std::list, возможно, это не для вас.

Также обратите внимание, что стеки не могут поддерживать итераторы (они в основном поддерживают только push и pop), поэтому большая часть разговоров о поддержке итераторов и алгоритмов выдает желаемое за действительное.

Answer 4

Я думаю, что тонкую обертку должно быть очень легко написать.что-то вроде 1-2 страниц, возможно, все в файле .h.Вместо того чтобы прочесывать Google, я бы уже написал это сам.