Windows provides a lockless singly linked list, as documented at this page: Win32 SList
I'm wondering if there's an existing good C++ wrapper around this functionality. When I say good, I mean it exports the usual STL interface as much as possible, supports iterators, etc. I'd much rather use someone else's implementation than sit down to write an STL-type container.
I think a thin wrapper should be very easy to write. something like 1-2 pages, possibly all in the .h file. Instead of combing google I'd write it myself already.
It's worth noticing that the published interface at the page quoted in the question does not in fact implement a linked list (though that may be underlying structure) - it implements a stack. So if you want the features of a linked list that classes such as std::list provide, this may not be for you.
Also notice that stacks cannot support iterators (they basically only support push and pop), so much of the talk of supporting iterators and algorithms is wishful thinking.
You could quickly get up and running with boost and ::boost::iterator_facade.
No it wouldn't be optimal or portable and iterator semantics are something you should hear Alexandrescou suddenly come out against at DevCon. You are not locking the container, you are locking (and potentially relocking and unlocking ) the operations. And locking the operation means serial execution, very simple. There is plenty of iterator manipulation that will be an unnecessary penalty for the abstraction being created.
From Mars view, iterator is hiding the pointer, and hiding under a semi-OO concept that is as odds as OO-vs-Distributed development is.. I'd use a 'procedural' interface for sure and make the users/maintainers pay attention to why it is necessary. Lock-free ops are only as good as 'all the parallel code' surrounding it. And classic examples as people keep giving scoped_lock wrapping reinvention since '96 credit, it produces pretty serial code.
Or use the atomic and Sutter's DDJ entries as reference for poor man way forward (and more than 10 years of unorderedness of Pentium Pro later).
(all that is really happening is that boost and DDJ is running after a .net and MS CCR train that is running after immutability, as well as intel train that is running after a good OO-similar abstraction for lockfree development. The problem is it cannot be done well and some people fight it time and time again; much like concurrent_vector nonsense of TBB. The same reason exceptions never materialised as non-problematic, especially across environments, and the same reason why vector-processing in CPUs is underutilised by C++ compilers and so on and on..)
You won't be able to layer an STL style interface on top of SList ever. In order to avoid memory management problems the only node in the list that is accessible is the head of the list. And the only way to access that node is to pop it off the list. This prevents two threads from having the same node and then one thread deleting that node while the other thread is still using it. This is what I mean by "memory management issues" and is a common problem in lock free programming. You could always pop the first node and then follow the "Next" pointers in the SLIST_ENTRY structs but this is an exceedingly bad idea unless you can guarantee that the list will not shrink, with nodes being deallocated, while you are reading it. Of course this still removes the head node from the list.
Basically you are trying to use SList wrong. For what it sounds like you want to do you just need to use an STL container and protect access to it using a lock. STL algorithms will not work with lock free data structures that are mutable like SList.
All that being said you could create a C++ wrapper around SList but it wouldn't be STL compatible.