www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - writefx and threads

reply Matthias Walter <walter mail.math.uni-magdeburg.de> writes:
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
Jan 25 2007
parent reply kris <foo bar.com> writes:
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.
Jan 25 2007
parent reply Matthias Walter <walter mail.math.uni-magdeburg.de> writes:
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
Jan 26 2007
parent Lars Ivar Igesund <larsivar igesund.net> writes:
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
Jan 26 2007