is sprintf thread safe?

问题:

is sprintf thread safe ?

//Global log buffer 
char logBuffer[20];

logStatus (char * status, int length)
{
  snprintf(logBuffer, 19, status);
  printf ("%s\n", logBuffer);
}

The thread safety of this function totally depends upon the thread safety of snprintf/sprintf .

Updates : thanks for ur answers . i dont mind, if the actual contents gts messed up. but want to confirm that the sprintf would not cause a memory corruption / buffer overflow going beyond 20 bytes in this case, when multiple threads are trying to write to logBuffer ?

回答1:

There is no problem using snprintf() in multiple threads. But here you are writing to a shared string buffer, which I assume is shared across threads.

So your use of this function would not be thread safe.

回答2:

You have several problems with your code.

1. Your usage of snprintf is very suspicious. Don't use it just to copy a string. Generally don't pass dynamically allocated strings with whatever content as format to any of the printf functions. They interpret the contents and if there is anything in them that resembles a %-format, you are doomed.
2. Don't use static buffers as you do. This is certainly neither thread safe not re-entrant.
3. Either use printf with an appropriate format directly, or replace the call by puts.

Then, Linux adheres to the POSIX standard, which requires that the standard IO functions are thread safe.

回答3:

Your question has an incorrect premise. Even if sprintf itself can be safely called from multiple threads at the same time (as I sure hope it can), your code is not protecting your global variable. The standard library can't possibly help you there.

回答4:

Regarding your update about not worrying if the logBuffer content get garbled:

I'm not sure why you want to avoid making your function completely thread safe by using a locally allocated buffer or some synchronization mechanism, but if you want to know what POSIX has to say about it, here you go (http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11):

Applications shall ensure that access to any memory location by more than one thread of control (threads or processes) is restricted such that no thread of control can read or modify a memory location while another thread of control may be modifying it. Such access is restricted using functions that synchronize thread execution and also synchronize memory with respect to other threads. [followed by a list of functions which provide synchronization]

So, POSIX says that your program needs to make sure mutilple threads won't be modifying logBuffer concurrently (or modifying logBuffer in one thread while reading it in another). If you don't hold to that, there's no promise made that the worst that will happen is garbled data in logBuffer. There's simply no promise made at all about what the results will be. I don't know if Linux might document a more specific behavior, but I doubt it does.

回答5:

"There is no problem using snprintf() in multiple threads."

Not true.

Not true, at least in case of POSIX functions.

All of the standard vararg functions are not mt-safe - this includes all the printf() family (1), but also every other variadic function as well (2)

1. sprintf() for example is: "MT-Safe locale|AS-Unsafe heap|AC-Unsafe mem" - what means, that it can fail if locale is set asynchronously or if asynchronous cancellation of threads is used. In other words, special attention must be paid when using such functions in MT environment.

2. va_arg is not mt-safe: |MT-Safe race:ap|AS-Safe|AC-Unsafe corrupt| - what means, that inter-locking is needed.

Additionally, what should be obvious, even totally mt-safe function can be used in unsafe way - what happens for example if two or more threads are operating the same data/memory areas.

回答6:

It's not thread safe, since the buffer where you sprintf is shared between all threads.

回答7:

"Do you have a refernce which says that they are not thread safe? When I Google, it seems that they are"

My previous answer to this question has been removed/deleted (why?), so I'll try again, using different approach:

1. AC (async. cancellation of threads): this is obviously a case when almost all of the "apparently MT-safe" code can fail, simply because the thread is interrupted at a random point of time, so none of synchronization methods are guaranted to work correctly (i.e. any form of mutex can't be really guranteed to work correctly)

2. Threads can use the same malloc() arena, what means, that if one of the threads will fail (i.e. it'll damage the malloc arena) then all the consecutive calls to malloc() will/can cause critical errors - this of course depends on system configuration - but it also means, that nobody should assume that malformed memory (de)allocations are safe.

Since all of the systems are providing the option to use different local settings, it is obvious, that async. change to the "locale" settings can cause errors...

Regards.