Thread safe printf?

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.

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).

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.

I was distracted by the title, and missed that essential point. You would certainly want sprintf to be thread safe!

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.

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.

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

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!

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" skrev i en meddelelse news:494a786d$0$15873$ snipped-for-privacy@dtext01.news.tele.dk...

Sorry I didn't think of checking this when you first posted. I checked the source, none of the printf variants in the IAR libraries are thread safe, this includes sprintf.

According to their AVR compiler documentation their sprintf() implementation is thread safe - so it is interesting if your inspection shows otherwise.

The FreeRTOS download includes a mini implementation of sprintf() that is thread safe. I normally use that regardless as it uses much less stack than standard library variants.