stdio performance in tango, stdlib, and perl

Walter Bright newshound at digitalmars.com
Sat Mar 24 22:06:26 PDT 2007


Sean Kelly wrote:
>> It does exactly one lock acquire/release for each printf, not for each 
>> character written.
> This is still far too granular for most uses.

I disagree. It's been working fine for nearly 20 years now. gcc 
implements it the same way, and it's hardly unusable for most uses.

>> The problem is such synchronization would be invented and added on by 
>> the user, making it impossible to combine disparate libraries that 
>> write to stderr, for example, in a multithreading environment.
> This is a valid point, but how often is it actually used in practice? 
> Libraries generally do not perform error output of their own, and 
> applications typically have a coherent approach for output.  In my time 
> as a programmer, I can't think of a single instance where default 
> synchronization to an output device actually mattered.  I can certainly 
> appreciate this for its predictable behavior, but I don't know how often 
> that predictability would actually matter to me.

It apparently comes up often enough in C++ to merit 59,000 hits on 
"multithreaded iostreams" and many web pages outlining attempts to solve 
the problem.

It is a problem that is solved by every C stdio for multithreaded 
environments, although the C standard does not mention the word "thread".

Multithreading threatens to become far more common, not less, as we move 
to multicore machines.

If that isn't compelling, ok, but I suggest at a minimum that Tango not 
lock into a design that *precludes* adding thread synchronization 
without changing user code.



More information about the Digitalmars-d mailing list