On 09/09/08 08:12, Garrett D'Amore wrote:
> Steve Clamage wrote:
>>
>>
>> On 09/09/08 02:35, Darren J Moffat wrote:
>>> Steve Clamage wrote:
>>>>>> 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.
>>>
>>> What does that mean ?
>>
>>
>> Standard Performance Evaluation Corporation
>> http://www.spec.org/
>> Sun, especially the software division, lives and dies by SPEC
>> performance measurements. Artificially reducing performance has
>> consequences for the entire company.
>
> That said, Darren's other comments seem particularly apropos -- if
> libraries are permitted to create threads at any time, then it becomes
> impossible for developers to predict whether their program (for
> non-trivial programs at least) will be MT or not, and therefore all
> libraries must be thread-safe.
>
> The libc should have an optimization that on single CPU systems the
> mutexes involved are noops. That doesn't help single threaded
> applications on SMP systems, but it does help single CPU systems at
> least. :-)
>
> Besides which, I thought uncontended mutexes were supposed to be *cheap*.
Each compiler release supports a range of Solaris versions. The
currently-shipping compilers support Solaris versions as early as
Solaris 8. We don't want to have different sets of instructions for
using the compiler on different Solaris versions.
In line with the Solaris Guarantee, we promise that binaries created on
an older Solaris version can be linked into a program created on a later
Solaris version.
The compiler default is to generate single-threaded programs. The
-DRE_ENTRANT macro is not set, and libthread is not linked.
To compile an MT program, we recommend using the -mt option, which takes
care of defining RE_ENTRANT and linking the thread library in the right
order. The entire program must use -mt consistently: it must appear on
every command line, or not appear on any command line. (I'm ignoring the
case where the linker is invoked directly instead of via cc or CC.)
The libraries we currently ship adjust automatically for single- or
multi-threaded use. The locking code is #ifdef'd away or becomes a no-op
for a single-threaded compilation.
Apache libstdcxx is different -- it must be built for single-threaded or
MT use.
Let's take the case where we provide only an MT version of the runtime
library.
I'm not clear on the consequences of linking code compiled without
-DRE_ENTRANT with MT code. Is that always safe? If so, maybe the only
issue would be performance. (We don't yet know whether performance is an
issue.)
If mixing MT and non-MT code is problematic, we must tell users to add
-mt when using libstdcxx. When we add support for libstdcxx to CC, it
can add -mt implicitly to every command line. But that still leaves this
case for Sun Studio 12, which supports Solaris 9, 10, and SNV:
% cc -c f1.c # on Solaris 9, single threaded
% CC -c -library=stdcxx f2.cc # on S10, implicit -mt
% CC -o myprog -library=stdcxx f1.o f2.o # implicit -mt
Will this program always work?
---
Steve Clamage, stephen.clamage at sun.com
