PSARC/2008/549 - Apache Standard C++ Library

[Steve Clamage]

On 9/8/2008 2:36 PM, Nicolas Williams wrote:
> On Mon, Sep 08, 2008 at 02:20:48PM -0700, Steve Clamage wrote:
>> The feature would not be available on Solaris 9 or earlier. We have 
>> precedent for such a limitation: full C99 conformance is similarly not 
>> available. But I don't think restricting the availability to 
>> SNV/OpenSolaris is acceptable. Currently, full Sun support (e.g. for 
> 
> Why not?  Plenty of things are in Solaris Nevada / OpenSolaris that will
> not be backported to Solaris 10.  Whether to backport is a business
> issue, not an ARC issue.

Yes, it's a business issue. But much of the discussion has been about 
whether a Solaris consolidation or the compiler team should be 
responsible for delivering what are, after all, components that can be 
used only with the Sun C++ compiler. I want to be sure the needs of the 
the software tools organization are met.

> 
>> [...]
>>
>> It might be possible to deliver a single version of the runtime library 
>> (per platform) compiled with -mt to be used by both MT and non-MT 
>> programs, but it would have performance implications for single-threaded 
>> programs. We think a better solution would be to have two libraries, to 
>> ensure no conflict between MT and non-MT code, and to eliminate 
>> gratuitous performance loss in single-threaded code. (In MT code, the 
>> library must lock critical regions of an object during manipulation by 
>> library functions.)
> 
> Solaris 10 and up have a unified process model.  Why should C++ on
> Solaris not have a unified process model too?

As I noted in the part that you quote, library data structures have 
critical regions that must be locked if manipulating functions are 
called by multiple threads.

The other two libraries that we ship have the locking calls controlled 
by macros in the headers visible to user code. When compiled without -mt 
(-D_REENTRANT), these macros turn into no-ops.

The design of libstdcxx buries these locks in the internals of the 
functions inside the library. If you have only an MT library, 
single-threaded programs pay the cost of these unneeded locks.

I agree with Stefan that we need to do some measurements to see whether 
the performance difference is important.

---
Steve Clamage, stephen.clamage at sun.com