Mess in printf output
serpiko666
how can I avoid that, when two threads (created with CreateThread()) call
printf() at the same time, the strings printed by the two threads are
messed together? In other words, is there a way that each call of ptintf()
is processed one by one separately?
Thanks!
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
David Schwartz
> Hi all,
> how can I avoid that, when two threads (created with CreateThread()) call
> printf() at the same time, the strings printed by the two threads are
> messed together? In other words, is there a way that each call of ptintf()
> is processed one by one separately?
> Thanks!
You need to coordinate access to a shared resource. There are many,
many different ways to do this. I would recommend replacing 'printf'
with a call to your own function that arbitrates access to the output
stream.
DS
Chris M. Thomasson
news:h0lomv$82k$1...@news.newsland.it...
> Hi all,
> how can I avoid that, when two threads (created with CreateThread()) call
> printf() at the same time, the strings printed by the two threads are
> messed together? In other words, is there a way that each call of ptintf()
> is processed one by one separately?
> Thanks!
In addition to David's advice, you should not use any CRT functions from
threads spawned with `CreateThread()':
http://msdn.microsoft.com/en-us/library/ms682453(VS.85).aspx
serpiko666
> I would recommend replacing 'printf'
> with a call to your own function that arbitrates access to the output
> stream.
Thanks. I have used EnterCriticalSection to serialize accesses to STDOUT.
Maybe it's not the smartest way, but it works... Can you indicate some
code samples of other methods?
Andrew Gabriel
riff.ra...@libero.it (serpiko666) writes:
> David Schwartz ha scritto:
>
>> I would recommend replacing 'printf'
>> with a call to your own function that arbitrates access to the output
>> stream.
>
> Thanks. I have used EnterCriticalSection to serialize accesses to STDOUT.
> Maybe it's not the smartest way, but it works... Can you indicate some
> code samples of other methods?
Don't know if Windows guarantees write()s are atomic below certain
size, but you could try building up the complete string into thread
specific buffers (e.g. using sprintf()), and then using write() to
output the completed buffer.
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
Dave Butenhof
> how can I avoid that, when two threads (created with CreateThread()) call
> printf() at the same time, the strings printed by the two threads are
> messed together? In other words, is there a way that each call of ptintf()
> is processed one by one separately?
> Thanks!
POSIX/UNIX requires that printf() itself be atomic; it's not legal that
two parallel calls to printf() from separate threads can mix their data.
But those two writes may appear on the output in either order.
That is, 'printf("hello");printf(" ");printf("world")' in one thread and
'printf("goodnight");printf(" ");printf("moon");' in another may result
in "hellogoodnight world moon" or "goodnighthello moonworld" but cannot
result in "hgeololdon iwgohrt" [...].
It's not entirely clear from your post what you're seeing. If you're
seeing something on the order of the last, it's possible that either
a) You haven't initialized Microsoft's c library for thread safety. (I
believe the idiots require you to do this manually?)
b) Their implementation is hopelessly broken. (Even for Microsoft, this
seems unlikely.)
If what you're seeing is essentially either of the other cases (output
from various threads appearing atomically but in random order), then you
need something more.
POSIX provides for locking stdio streams across a sequence of input or
output operations, delaying parallel calls until you've completed the
sequence.
So:
flockfile(stdout);
printf("hello");
printf(" ");
printf("world");
funlockfile(stdout);
in one thread and the equivalent in the other can print "hello
worldgoodnight moon" or "goodnight moonhello world" but cannot
interleave the two sequences.
If windows fails to implement flockfile/funlockfile, you can fake it by
using your own synchronization around YOUR stdout accesses, as long as
no independent code in the process is ALSO writing.
Sergei Organov
[...]
> If windows fails to implement flockfile/funlockfile, you can fake it
> by using your own synchronization around YOUR stdout accesses, as long
> as no independent code in the process is ALSO writing.
What is recommended way to implement such locking in terms of POSIX
primitives? Mutex? Seems unlikely it's a good fit taking into account
that it will be locked for prolonged periods of time. Or is it?
Re-phrasing this, how typical implementation of flockfile/funlockfile
looks like?
-- Sergei.
Steve Watt
The typical implementation of flockfile()/funlockfile() is a recursive
mutex. Pretty straightforward, really. The mutex doesn't have to be
recursive, but it makes life simpler because the stdio functions can
simply lock again; there aren't generally condition waits in stdio
implementations.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3"
Internet: steve @ Watt.COM Whois: SW32-ARIN
Free time? There's no such thing. It just comes in varying prices...
Casper H.S. Dik
>In article <h0rkje$td5$1...@aioe.org>, Sergei Organov <o...@javad.com> wrote:
>>Dave Butenhof <david.b...@hp.com> writes:
>>[...]
>>> If windows fails to implement flockfile/funlockfile, you can fake it
>>> by using your own synchronization around YOUR stdout accesses, as long
>>> as no independent code in the process is ALSO writing.
>>
>>What is recommended way to implement such locking in terms of POSIX
>>primitives? Mutex? Seems unlikely it's a good fit taking into account
>>that it will be locked for prolonged periods of time. Or is it?
>>
>>Re-phrasing this, how typical implementation of flockfile/funlockfile
>>looks like?
>The typical implementation of flockfile()/funlockfile() is a recursive
>mutex. Pretty straightforward, really. The mutex doesn't have to be
>recursive, but it makes life simpler because the stdio functions can
>simply lock again; there aren't generally condition waits in stdio
>implementations.
A thread is allow to call flockfile twice and then it needs to call
funlockfile twice. It doesn't need to use a recursive mutex but it
needs to act like one. (An earlier Solaris implementation uses a normal
mutex, a count and a condvar. The current Solaris implementation uses
a recursive thread mutex)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Dennis Jones
> how can I avoid that, when two threads (created with CreateThread()) call
> printf() at the same time, the strings printed by the two threads are
> messed together? In other words, is there a way that each call of ptintf()
> is processed one by one separately?
> Thanks!
It is my understanding (perhaps mistakenly) that most implementations of
fprintf are thread-safe. As a quick test, you might just try using
fprintf( stdout, ... ) and see if that resolves the intertwined output.
- Dennis