Существует ли приличная оболочка C ++ вокруг безлимитного SList в Win32?

Question

Windows предоставляет список одноблочных ссылок без блокировки, как описано на этой странице: Win32 SList

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

Вы можете быстро начать работать с boost и :: boost :: iterator_facade.

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

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

Или используйте атомарные записи и записи DDJ Саттера в качестве справочной информации о дальнейших действиях бедного человека (и более чем 10-летней неупорядоченности Pentium Pro позже).

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

Answer 4

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