Boost logo

Boost :

From: John Torjo (john.lists_at_[hidden])
Date: 2004-09-05 08:25:52

> Browsing through the older posts I could not find any relevant discussion.
> What is the opinon on implementing thread-safe containers?

My personal oppinion is that this would be solving the wrong problem.
It's thread-safe data that you need. Which could include a lot more
additional data besides a thread-safe container.

I'm always joggling (creating small classes) that allow me to do this:

struct my_great_type {

struct ts_data {
ts_obj<ts_data> m_info;


// the one and only way to get access to ts_data
// acquires thread-safe lock
ts_obj<ts_data>::data val = m_info.use();
//... use val here
// when it goes out of scope, lock is released.

> Java library has them, for example, and, since extending existing containers
> to be thread safe using locks is a work each client would have to repeat, it
> looks like a good candidate for standardized library implementation.
> As for more efficient lock-free impleentations (using CAS) Microsoft has
> (relatively recently) added singly linked lock-free list to Win32 API. There

could you post a link? thanks.

> are examples of lock-free implementations of doubly linked STL list using
> older Valois algorithm.
> I would argue that most of multi-threaded programs need thread-safe
> containers.

I tend not to agree with you (see above).


John Torjo
-- john_at_[hidden]
Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- v1.3beta released - check out splitter/simple_viewer,
    a File Explorer/Viewer all in about 200 lines of code!
Professional Logging Solution for FREE
-- (logging           - C++)
--         (viewing/filtering - Win32)
--        (debugging         - Win32)

Boost list run by bdawes at, gregod at, cpdaniel at, john at