digitalmars.D.learn - writefx and threads
- Matthias Walter (7/45) Jan 25 2007 of course, order of execution cannot be determined in advance, but I add...
- kris (11/66) Jan 25 2007 It's often reasonable for a library to avoid using mutex, since they can...
- Matthias Walter (3/74) Jan 26 2007 thank you, this sounds well. Where can I get Tango? http://www.dsource.o...
- Lars Ivar Igesund (8/94) Jan 26 2007 An alpha slash beta release should hopefully be out in a few days, toget...
Jari-Matti Mäkelä Wrote:Matthias Walter wrote: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 WalterHello, 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 fromsome 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.
Jan 25 2007
Matthias Walter wrote:Jari-Matti Mäkelä Wrote: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.Matthias Walter wrote: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 WalterHello, 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 fromsome 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.
Jan 25 2007
kris Wrote:Matthias Walter wrote: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 WalterJari-Matti Mäkelä Wrote: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.Matthias Walter wrote: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 WalterHello, 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 fromsome 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.
Jan 26 2007
Lars Ivar Igesund <larsivar igesund.net> Matthias Walter wrote:kris Wrote: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 TangoMatthias Walter wrote: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 WalterJari-Matti Mäkelä Wrote: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.Matthias Walter wrote: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 WalterHello, 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 fromsome 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.
Jan 26 2007