std::string and pthread_mutex_lock / pthread_mutex_lock

[brad]

I've got a multithreaded application using std::string in Linux.
Performance is not very good so I ran Quantify(tm) to look at what is
happening.
Most of the time my app was calling pthread_mutex_lock and
pthread_mutex_unlock from different std::string methods. Since the
strings I'm using are never used in another thread I was wondering
whether I could get rid of these mutex calls altogether? Are there
some compiler options available (like in Solaris) to change the
behaviour of std::string?
<>bb

 

[Axter]

I've got a multithreaded application using std::string in Linux.
Performance is not very good so I ran Quantify(tm) to look at what is
happening.
Most of the time my app was calling pthread_mutex_lock and
pthread_mutex_unlock from different std::string methods. Since the
strings I'm using are never used in another thread I was wondering
whether I could get rid of these mutex calls altogether? Are there
some compiler options available (like in Solaris) to change the
behaviour of std::string?
<>bb

Are the lock and unlock code inside your code, or in the std::string
implemenation?

Where exactly is the lock/unlock code residnig?

 

[Uenal Mutlu]

I've got a multithreaded application using std::string in Linux.
Performance is not very good so I ran Quantify(tm) to look at what is
happening.
Most of the time my app was calling pthread_mutex_lock and
pthread_mutex_unlock from different std::string methods. Since the
strings I'm using are never used in another thread I was wondering
whether I could get rid of these mutex calls altogether? Are there
some compiler options available (like in Solaris) to change the
behaviour of std::string?

Very curios. I was thinking that pthreads is an optional library.
So STL's std::string should know nothing about pthreads or any threads.
Actually, it is the user's job to synchronize simultanous access from
multiple threads, the STL implementation should not try to do that for
the user because the library cannot know what the application logic will
be for obvious reasons.
I would say it's a bad STL implementation.

 

[Pete Becker]

Very curios. I was thinking that pthreads is an optional library.
So STL's std::string should know nothing about pthreads or any threads.

Implementations of the standard library can (and do) use
system-dependent support functions. One reason for putting things in the
standard library is that they can't be implemented portably.

 

[Uenal Mutlu]

Implementations of the standard library can (and do) use
system-dependent support functions. One reason for putting things in the
standard library is that they can't be implemented portably.

Sure, but it should not be in this particular case because
it seems to be an unnecessary overhead built into
implementation which slows down the application.
What is your opinion on what the OP asked?

 

[Axter]

Very curios. I was thinking that pthreads is an optional library.
So STL's std::string should know nothing about pthreads or any threads.
Actually, it is the user's job to synchronize simultanous access from
multiple threads, the STL implementation should not try to do that for
the user because the library cannot know what the application logic will
be for obvious reasons.
I would say it's a bad STL implementation.

Not necessarily. The implementation code be using a lock/unlock to
handle shared variables like a reference counter.

 

[Pete Becker]

Sure, but it should not be in this particular case because
it seems to be an unnecessary overhead built into
implementation which slows down the application.

This has very little to do with your original non sequitur.

What is your opinion on what the OP asked?

He didn't provide enough details for anyone to base an opinion on. Nor
did he ask for one.

 

[Uenal Mutlu]

Not necessarily. The implementation code be using a lock/unlock to
handle shared variables like a reference counter.

Hmm.. but, are there such shared variables inside the implementation of std::string?
I cannot see for what they might be needed esp. in std::string.

 

[Axter]

Hmm.. but, are there such shared variables inside the implementation of std::string?
I cannot see for what they might be needed esp. in std::string.

Yes.
The C++ standard allows for the implementation to have reference
counters.
If you have an std::string implementation that has a referance counter,
then you are sharing data between multiple instances of std::string in
such code as the following:

std::string data1 = "Hello World";
std::string data2(data1);
std::string data3 = data1;

In above code all three std::string variables are pointing to the same
buffer when using an implementation that uses reference counters.
When these objects go out of scope, they'll attempt to modify the
reference counter by decreasing it by one. (--refcount)
For a thread safe std::string version, this has to be synchronized.

 

[Uenal Mutlu]

Yes.
The C++ standard allows for the implementation to have reference
counters.
If you have an std::string implementation that has a referance counter,
then you are sharing data between multiple instances of std::string in
such code as the following:

std::string data1 = "Hello World";
std::string data2(data1);
std::string data3 = data1;

In above code all three std::string variables are pointing to the same
buffer when using an implementation that uses reference counters.
When these objects go out of scope, they'll attempt to modify the
reference counter by decreasing it by one. (--refcount)
For a thread safe std::string version, this has to be synchronized.

I'm afraid such a reference counted STL implementation
would IMO give for some operations a different result than
a standard STL implementation. Therefore I doubt it could
be called STL.

 

[Axter]

at Since

I'm afraid such a reference counted STL implementation
would IMO give for some operations a different result than
a standard STL implementation. Therefore I doubt it could
be called STL.

Most STL implementations use reference counting for std::string.

Most major compilers like GNU, VC++ 6.0, and 7.x come with std::string
that has reference counting in the implementation.

Implementations that don't have reference counting are the exception,
and not the rule.

 

[Howard Hinnant]

Most STL implementations use reference counting for std::string.

Most major compilers like GNU, VC++ 6.0, and 7.x come with std::string
that has reference counting in the implementation.

Implementations that don't have reference counting are the exception,
and not the rule.

Last time I counted, there were 4 major independent implementations.
Half use a refcounted string and half use the sso (short string
optimization). Dinkumware and Metrowerks (current versions) are the
ones using sso.

-Howard

 

[Axter]

Last time I counted, there were 4 major independent implementations.

Half use a refcounted string and half use the sso (short string
optimization). Dinkumware and Metrowerks (current versions) are the
ones using sso.

-Howard

I believe there are more then 4 major independent implement, and some
versions allow you to turn off the reference counter. (See Scott
Meyers Effective STL)

However, most of the major compilers come with versions that use
reference counters.

 

[Howard Hinnant]

I believe there are more then 4 major independent implement, and some
versions allow you to turn off the reference counter. (See Scott
Meyers Effective STL)

However, most of the major compilers come with versions that use
reference counters.

Sorry, I counted wrong:

Dinkumware
gcc
Metrowerks
Rogue Wave
STLport

gcc and STLport have a somewhat intertwined heritage and I mistakenly
counted them as one.

Scott's ESTL counted 4, and diplomatically named them A - D. Note that
this fine book is copyrighted 2001.

I can tell you for sure that B is Metrowerks Windows Pro 6, released in
2000 (which was refcounted with an internal mutex at the time). And D
is Dinkumware (the one with short string optimization), not sure of the
version number. Since this book was written, Metrowerks changed to a
short string optimization (making somewhat different design tradeoffs
than implementation D). To the best of my knowledge the other
implementations are still reference counted, but my information may not
be up to date.

-Howard

 

[Axter]

Sorry, I counted wrong:

Dinkumware
gcc
Metrowerks
Rogue Wave
STLport

gcc and STLport have a somewhat intertwined heritage and I mistakenly

counted them as one.

Scott's ESTL counted 4, and diplomatically named them A - D. Note that
this fine book is copyrighted 2001.

FYI:
He keeps an updated Errata, with last update 25 April 2005
See following link:
http://www.aristeia.com/BookErrata/estl1e-errata_frames.html

I agree, it's a fine book.
Moreover, I consider his complete set of Effective C++, More C++, & STL
to be the best three C++ books I've ever read.
I recommend these three books over any other C++ books, to include
books by Stroustrup and Sutter.