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