writefx and threads

[Lars Ivar Igesund]

Matthias Walter wrote:

> kris Wrote:
> 
>> 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.
> 
> thank you, this sounds well. Where can I get Tango?
> http://www.dsource.org/projects/tango doesn't work for me ("Forbidden"),
> google only reports some announcements and cached svn code. If Tango isn't
> complete, that's okay to me, I just want to take a look at it, as it seems
> interesting.
> 
> Matthias Walter

An alpha slash beta release should hopefully be out in a few days, together
with an opening of the available resources.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Dancing the Tango