|
Boost : |
From: Tony Juricic (tonygeek_at_[hidden])
Date: 2004-09-06 05:38:08
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk