I am not sure I understand it well, so let's try with a concrete example of FIFO queue. Let's say you are asynchronously receiving message blocks (not necessarily of fixed size) and you implement that with two threads: - one is accumulating data until message end is found and puts the block in the queue - another reads and parses message blocks
At this point the chunkiness of the data and the fact that data for message blocks arrive asynchronously is modelled via element membership in the queue container which must be accessed in a thread-safe manner.
Use mutexes.
Thread-safe queue (whether lock-free or using 'ordinary' locks on all accessors) seems a way to implement this without programmer having to explicitly consider threading issues. One programmer puts the data block, another picks them and parses them.
In my experience, I hardly need just a container to be thead-safe. I usually need more data in addition to the container (which needs to be thread-safe). For instance, an extra latest_access_time, out_file, used_for_the_first_time, etc. Thus, to me, the benefit of having a thread-safe container is very small. Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)