On 9/8/2008 3:31 PM, Nicolas Williams wrote: > On Mon, Sep 08, 2008 at 03:05:22PM -0700, Steve Clamage wrote: >> On 9/8/2008 2:36 PM, Nicolas Williams wrote: >>> 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. > > I thought that getting the Sun Studio team involved was all about making > sure that you had no architectural objections, and that whatever such > bjections you had were ironed out. > >>> 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. > > I understood that. The same is true of many C libraries in Solaris. > >> 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. > > But it's also important to consider whether the common uses are in MT or > single-threaded programs. Why even bother measuring the cost for > single-threaded programs if they are not the target, or if no > consequential single-threaded programs exist that might use this > library?
SPEC. --- Steve Clamage, stephen.clamage at sun.com
