stdio performance in tango, stdlib, and perl

Andrei Alexandrescu (See Website For Email) SeeWebsiteForEmail at erdani.org
Sat Mar 24 19:35:08 PDT 2007


James Dennett wrote:
> Walter Bright wrote:
>> James Dennett wrote:
>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>> cout << a << b;
>>>>
>>>> can't guarantee that a and b will be adjacent in the output. In
>>>> contrast,
>>>>
>>>> printf(format, a, b);
>>>>
>>>> does give that guarantee. Moreover, that guarantee is not between
>>>> separate threads in the same process, it's between whole processes!
>>>> Guess which of the two is usable :o).
>>> As you appear to be saying that printf has to flush every
>>> time it's used, I'd guess that it's unusable for performance
>>> reasons alone.
>> In order for printf to work right it does not need to flush every time
>> (you're right in that would lead to terrible performance). The usual
>> thing that printf does is only do a flush if isatty() comes back with
>> true. In fact, flushing the output at the end of each printf would not
>> mitigate multithreading problems at all. In order for printf to be
>> thread safe, all that's necessary is for it to acquire/release the C
>> stream lock (C's implementation of stdio has a lock associated with each
>> stream).
> 
> That would be true, except that Andrei wrote that
> the guarantee applied to separate processes, and
> that can only be guaranteed if you both use some
> kind of synchronization between the processes *and*
> flush the stream.
> 
> Andrei's claim went beyond mere thread-safety, and
> that was what I responded to.

Lines don't have to appear at exact times, they only must not 
interleave. So printf does not have to flush often. I've used 
printf-level atomicity for a long time on various systems and it works 
perfectly.

Is a system-dependent assumption? I don't know. It sure is there and is 
very helpful on all systems I used it with.


Andrei



More information about the Digitalmars-d mailing list