writefx and threads

[kris]

Matthias Walter wrote:
> Jari-Matti Mäkelä Wrote:
> 
> 
>>Matthias Walter wrote:
>>
>>>Hello,
>>>
>>>I've written a simple threaded application, where 30 threads only print some messages. If I use writefln() for this, it looks like this:
>>>
>>>...
>>>Thread started...
>>>Thread finished.
>>>TTThread started...
>>>Thread finished.
>>>hread started...
>>>Thread finished.
>>>hread started...
>>>Thread finished.
>>>...
>>>
>>>If I use standard printf(), this doesn't happen, it looks like
>>>
>>>...
>>>Thread started...
>>>Thread finished...
>>>Thread started...
>>>Thread finished...
>>>...
>>>
>>>Looking at std/stdio.d, there's a "__fp_lock(fp);" call in writefx(), but it seems to me,
>>>this doesn't help to sync the output routines. Or are output routines not
>>>supposed to be synced by default? If yes, this seems to be okay from
>>
>>some point of view,
>>
>>>but is somehow irritating!
>>
>>D uses buffered I/O. You may need to explicitly call flush() to finish
>>all output before sending new. One other thing, without thread
>>synchronization there is no guarantee that the threads are run in a
>>specific order.
>>
>>BTW, please use this newsgroup for reporting bugs, there's
>>digitalmars.D.learn for asking questions.
>>
> 
> 
> of course, order of execution cannot be determined in advance, but I added fflush(stdout); right after my writef() call. Nothing changed so far.
> 
> How do I sync the threads that output of lines doesn't get interrupted? Of course,
> one possibility is to put a mutex around the FILE object, checking it before write,
> but isn't it normally the case that it already has a mutex to protect against
> concurrent writes? as my example shows, printf from glibc does this.
> 
> Matthias Walter

It's often reasonable for a library to avoid using mutex, since they can 
affect performance quite notably. For example, Tango doesn't have a 
mutex in Stdout, but instead support the following idiom:

sychnronized (Stdout)
               Stdout ( ..... );

Which amounts to what your after, I think?

Tango also has pretty good 'logging' facilities [1], which are atomic in 
nature, and also expose the thread-id. It's based on the Log4J model.

[1] where logging is a redirectable, runtime configurable, network 
capable mechanism for tracing application execution & behaviour.