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

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.

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

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