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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

string and __thread


As I understand it, much (most?) of the contention observed for 
basic_string<> in heavily-threaded real-world programs occurs in fights 
over access to the reference count on the (single) static empty-string 
_Rep object.

It occurs to me that we might declare that object "__thread", so there
would be as many as there are threads, reducing contention scalably as 
the number of threads increases, and (as the number of threads exceeds 
the number of CPUs) beyond.

This would not eliminate contention, as any thread might "use" the
empty-string object that is static to any other thread, but the 
incidental traffic in increments and decrements to any one instance
would be much less.  

I wonder if declaring it __thread makes it much more expensive to get to.

Another alternative would be to change the functions that increment
and decrement the reference count, and first compare the address they
propose scribbling against the known empty-string address, and then
just not change it when the address matches.

Experiments should be pretty easy to do.  Is there anybody out there
who relies heavily on strings and lots of threads, who can perform some 
real-world tests?

Nathan Myers
ncm-nospam at cantrip dot org


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