John Torjo wrote:
Thus, to me, the benefit of having a thread-safe container is very small.
I see similar 'philosophy' in SGI STL. I wouldn't deny that thread-safety is, more often than not, more complex than thread-safe container access. However, at the same time, I see (and have seen) a large class of problems that require only container's thread-safety, plus, more complex scenarios typically require container's thread-safety for starters (as you wrote). Therefore, I see no harm, quite on the contrary, in having a separate class of robust, library-provided thread-safe containers. The existing research into wait-free and lock-free containers (to the point of processors implementing CAS and even DCAS) must have some basis in real requirements?! So 'my' philosophy' would be: while no library implementation can solve all thread-safety requirements that arise in everyday use, at certain basic, 'mechanical' level I would like to be able to work with the container and completely ignore threading issues, happy in the knowledge that library solved them for me in the most efficient way. IOW, I can say to a junior programmer, inexperienced with mutexes and threading: just use this container for your algorithm. Tony