MSDN seems to imply that you can link with a thread safe version of the
standard C++ template library. I'm currently using VC++ 6.0.

However, does this just mean that the library is re-entrant and uses a
locked allocator, or does it mean that you can have multiple threads
simultaneously updating a single STL object?

For example, if I wanted to have multiple threads updating the same STL
queue<> instance, would I have to add explicit locking code around the
updates?

It means at least that much.

That much is not guaranteed at all.

Absolutely yes.

The alternative, providing locks for every use
of containers and other objects, is way too
costly since most usage is single threaded,
even in multi-threaded programs.

--
Larry Brasfield
Above opinions may be mine alone.

In that case, an ideal thing to be able to do would be to derive a "locked" version of such classes -
locked_map<>
locked_queue<>
etc.

I don't suppose anyone's heard of something like that?

For example, say I knew that it would be a queue of std::string's, I could
try writing something that uses the MFC CCriticalSection and CSingleLock classes
like the following:

typedef std::queue<std::string> string_queue;
class message_queue : public string_queue {
    private:
        CCriticalSection this_section;
    public:
        value_type& front() {
            CSingleLock lock(&this_section, true);
            return string_queue::front();
        }

        // and similar wrapper methods for EVERY SINGLE non-const accessor method

However, implementing this would be tedious don't you think? Especially for every king of STL object. Do
you know of anyone
that's already "done" this tedious task (e.g. adding another template parameter for an optional "lock"
class that the user can supply)?

Or, does anyone know of some more elegant way of achieving the same thing? e.g. Doing some clever trick
with the template parameters? (I can't think of one myself but suspec that with all of C++'s bell's and
whistles, something might be arranged...)

Its not too hard to make collections optionally thread safe and lockable.
All the collections in my CIDLib libraries are optionally
threadsafe/lockable on a per-instance basis. Each individual method will be
threadsafe, or you can lock it and do multiple operations atomically. It
uses my standard locker janitor, which can lock anything that implements an
MLockable interface. If you don't use it, the overhead is pretty trivial,
though I'm sure someone could come up with a really high performance
scenario where it might become an issue. But, for such people, the
implementation of some custom data structures is a small price to pay
relative to providing such a clean and powerful architecture for the other
98% of users.

--------------------------
Dean Roddey
The CIDLib Class Libraries
Charmed Quark Software

http://www.charmedquark.com

"100% Substance Free. More cost, less content"