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 {

private:
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).

Best,
John

-- 
John Torjo
Freelancer
-- john_at_[hidden]
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)

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk