EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

Thread safe printf?

Started by JeGy December 18, 2008
Hi,

does anyone here know
if the IAR AVR C-compiler sprintf() and associated functions
are thread safe in in multi-tasking, e.i. FreeRTOS?

Regards

Jens 


"JeGy" <gydesen.jensREMOVE@THISgmail.com> wrote in message 
news:494a786d$0$15873$edfadb0f@dtext01.news.tele.dk...
> Hi, > > does anyone here know > if the IAR AVR C-compiler sprintf() and associated functions > are thread safe in in multi-tasking, e.i. FreeRTOS? > > Regards > > Jens
I just had a quick look at the manual, where I find listed under functions that are NOT thread safe: "Every function that uses files in some way. This includes printf, scanf, getchar, and putchar. The functions sprintf and sscanf are not included." Looks like you are going to have to use a mutex to guard printf()'s, or use some other method to serialise access. For example you could have a print task that is the only task that is permitted to call printf(). If any other task wants to output a message, rather than calling printf() explicitly itself it instead sends the message it wants to print out to the print task. -- Regards, Richard. + http://www.FreeRTOS.org Designed for microcontrollers. More than 7000 downloads per month. + http://www.SafeRTOS.com Certified by T&#4294967295;V as meeting the requirements for safety related systems.
On Thu, 18 Dec 2008 17:21:07 +0100, JeGy wrote:

> Hi, > > does anyone here know > if the IAR AVR C-compiler sprintf() and associated functions are thread > safe in in multi-tasking, e.i. FreeRTOS? > > Regards > > Jens
At a top level, printf isn't really thread safe, at least to the extent that you cannot use printf in a lot of otherwise acceptable ways that don't end up with mangled printout. Why? Because if thread A prints out "How do I love you?", then thread B prints out "Toilet Clogged!!\n", then thread A prints out " Let me count the ways.\n", each thread will be using printf "acceptably", yet the output will be puzzling, at best. So were I developing a library, I wouldn't have a great deal of motivation to make printf thread safe (fprintf, OTOH, should be thread safe for any individual file). -- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
The OP asked about "sprintf()", although the thread subject is
misleading.

If that's the case, "sprintf()" may well be thread-safe according to
the answer of Richard.

Thread-safe "printf()" is not hard to do with the usual ring buffer,
and with enough buffer size the calls won't be blocking more than the
formatting time. But for AVR this is overkill.
On Fri, 19 Dec 2008 03:36:27 -0800, vladitx wrote:

> The OP asked about "sprintf()", although the thread subject is > misleading.
I was distracted by the title, and missed that essential point. You would certainly want sprintf to be thread safe!
> If that's the case, "sprintf()" may well be thread-safe according to the > answer of Richard. > > Thread-safe "printf()" is not hard to do with the usual ring buffer, and > with enough buffer size the calls won't be blocking more than the > formatting time. But for AVR this is overkill.
I'm not saying that it would be hard to _do_; my point is that printf is designed with the underlying assumption that there is one data source that is printing to one data sink, and so there is nothing in the 'normal usage' of printf that makes its usage inherently thread safe. If you want to print messages to a common output (such as logging or what not), then you need to package those messages up as whole entities and send them, so they don't get scrambed up with one another. Printf is simply not suited to provide that functionality. -- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Tim Wescott <tim@seemywebsite.com> writes:
> On Thu, 18 Dec 2008 17:21:07 +0100, JeGy wrote: > > > does anyone here know > > if the IAR AVR C-compiler sprintf() and associated functions are thread > > safe in in multi-tasking, e.i. FreeRTOS? > > > > Regards > > > > Jens > > At a top level, printf isn't really thread safe, at least to the extent > that you cannot use printf in a lot of otherwise acceptable ways that > don't end up with mangled printout. Why? Because if thread A prints out > "How do I love you?", then thread B prints out "Toilet Clogged!!\n", then > thread A prints out " Let me count the ways.\n", each thread will be > using printf "acceptably", yet the output will be puzzling, at best. > > So were I developing a library, I wouldn't have a great deal of > motivation to make printf thread safe (fprintf, OTOH, should be thread > safe for any individual file).
How is it that one variant of printf() can be "thread-safe" when another isn't? They're all the same except for the destination of the result.

Tim Wescott wrote:

> I'm not saying that it would be hard to _do_; my point is that printf is > designed with the underlying assumption that there is one data source > that is printing to one data sink, and so there is nothing in the 'normal > usage' of printf that makes its usage inherently thread safe. If you > want to print messages to a common output (such as logging or what not), > then you need to package those messages up as whole entities and send > them, so they don't get scrambed up with one another. Printf is simply > not suited to provide that functionality.
Unless stated explicitly, *.printf functions should not be assumed to be thread safe. Reason: format conversions and i/o errors modify the global variables such as errno. If the local thread storage is supported in the stddio library and by the OS, then *.printf functions are safe. However it is not a big deal to protect *.printf by a semaphore anyway. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
On Fri, 19 Dec 2008 09:50:58 PST,
mojaveg@mojaveg.lsan.mdsg-pacwest.com (Everett M. Greene) wrote:

>Tim Wescott <tim@seemywebsite.com> writes: >> On Thu, 18 Dec 2008 17:21:07 +0100, JeGy wrote: >> >> > does anyone here know >> > if the IAR AVR C-compiler sprintf() and associated functions are thread >> > safe in in multi-tasking, e.i. FreeRTOS? >> > >> > Regards >> > >> > Jens >> >> At a top level, printf isn't really thread safe, at least to the extent >> that you cannot use printf in a lot of otherwise acceptable ways that >> don't end up with mangled printout. Why? Because if thread A prints out >> "How do I love you?", then thread B prints out "Toilet Clogged!!\n", then >> thread A prints out " Let me count the ways.\n", each thread will be >> using printf "acceptably", yet the output will be puzzling, at best. >> >> So were I developing a library, I wouldn't have a great deal of >> motivation to make printf thread safe (fprintf, OTOH, should be thread >> safe for any individual file). > >How is it that one variant of printf() can be "thread-safe" >when another isn't? They're all the same except for the >destination of the result.
I don't think fprintf() is any better than printf(). Actually the printf()/fprintf() function itself are maybe threadsafe (neglecting the errno), but the underlying I/O is not thread-safe with respect to single characters. I haven't seen a (f)printf() implementation which uses static variables, so the function is thread-safe. -- 42Bastian Do not email to bastian42@yahoo.com, it's a spam-only account :-) Use <same-name>@monlynx.de instead !
bastian42@yahoo.com (42Bastian Schick) writes:

> On Fri, 19 Dec 2008 09:50:58 PST, > mojaveg@mojaveg.lsan.mdsg-pacwest.com (Everett M. Greene) wrote: >
[...]
> > I don't think fprintf() is any better than printf(). > Actually the printf()/fprintf() function itself are maybe threadsafe > (neglecting the errno), but the underlying I/O is not thread-safe with > respect to single characters. > > I haven't seen a (f)printf() implementation which uses static > variables, so the function is thread-safe.
There are implementations of floating point math that are not thread-safe... so there must certainly also be printf ones too! -- John Devereux
Hi everybody,


Thanks for your answers and comments, is is good to know that one have 
friends out there when problems arise.

I am sorry that the subject was misleading, and I was not aware of the 
significant differences between sprintf and printf.

However, I have made my own thread safe sprintf function, and the embedded 
software now runs perfect.

So the conclusion is, that in this specific case, the sprintf was not thread 
safe

Best regards and a Happy Christmas

Jens

"JeGy" <gydesen.jensREMOVE@THISgmail.com> skrev i en meddelelse 
news:494a786d$0$15873$edfadb0f@dtext01.news.tele.dk...
> Hi, > > does anyone here know > if the IAR AVR C-compiler sprintf() and associated functions > are thread safe in in multi-tasking, e.i. FreeRTOS? > > Regards > > Jens >

The 2024 Embedded Online Conference