standard containers as local variables in multi-threaded application

In C++11, std::allocator is thread safe. From its definition:

20.6.9.1/6: Remark: the storage is obtained by calling ::operator new(std::size_t)

and from the definition of ::operator new:

18.6.1.4: The library versions of operator new and operator delete, user replacement versions of global operator new and operator delete, and the C standard library functions calloc, malloc, realloc, and free shall not introduce data races (1.10) as a result of concurrent calls from different threads.

C++03 had no concept of threads, so any thread safety was implementation-specific; you'd have to refer to your implementation's documentation to see what guarantees it offered, if any. Since you're using Microsoft's implementation, this page says that it is safe to write to multiple container objects of the same class from many threads, which implies that std::allocator is thread-safe.

In C++11 this would be addressed for the default allocator in:

20.6.9.1 allocator members [allocator.members]

Except for the destructor, member functions of the default allocator shall not introduce data races (1.10) as a result of concurrent calls to those member functions from different threads. Calls to these functions that allocate or deallocate a particular unit of storage shall occur in a single total order, and each such deallocation call shall happen before the next allocation (if any) in this order.

Any user-provided allocator would have to hold to the same constraints if it were going to be used across different threads.

Of course, for earlier versions of the standard, nothing is said about this since they didn't talk about multithreading. If an implementation were to support multithreading (as many or most do), it would be responsible for taking care of those issues. Similar to the way implementations provide a thread-safe malloc() (and other library functions) for C and C++ even though the standards prior to very recently said nothing about that.

As you may have already figured, there is not going to be an easy yes or no answer. However, I think this may help:

http://www.cs.huji.ac.il/~etsman/Docs/gcc-3.4-base/libstdc++/html/faq/index.html#5_6

I quote verbatim:

5.6 Is libstdc++-v3 thread-safe?

libstdc++-v3 strives to be thread-safe when all of the following conditions are met:

The system's libc is itself thread-safe, gcc -v reports a thread model other than 'single', [pre-3.3 only] a non-generic implementation of atomicity.h exists for the architecture in question.