This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

No Subject


You can have multiple threads safely reading a container, but
if you plan to write/update/munge a container, no-one else can
be reading it.

(there really is no way for them to lock some things internally,
ie:

	typedef map<string, string> SSMap;

	SSMap foo, bar;

	foo["a"] = bar["a"];

Each half  of the assignment would need to lock the container, 
but what you really need is a lock around the entire statement.

Strangely enough, it seems that on Solaris, the Alloc classes 
aren't threadsafe (or is it just my underlying malloc that's
bogus), and I -must- -D_PTHREADS in order for the STL to 
serialize access to allocations.

Elsewise, simple copy-constructoring a container will occasionally
segfault.

Note though, wrapping that Allocator with a lock gives less-than-stellar
performance.

Are there plans in 1.1.2 to include the most recent SGI STL?

-Bob



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]