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
