Is it thread safe to call printf in threads that run simultaneously?

Question

Possible Duplicate:
stdout thread-safe in C on Linux?

Say thread1 and thread2 are similar and at the end of their jobs they both printf. Is it thread safe or do they have to lock printf somehow?

Is it related to stdout? What if one does fflush(stdout) after each printf? Does it change anything?

Solution

The POSIX.1 and C-language functions that operate on character streams (represented by pointers to objects of type FILE) are required by POSIX.1c to be implemented in such a way that reentrancy is achieved (see ISO/IEC 9945:1-1996, §8.2).

refer to Thread-safety and POSIX.1

Note: Some functions can be reentrant or non-reentrant, depending on their arguments.

Comments

[R.. GitHub STOP HELPING ICE]

These functions are not reentrant. They are thread-safe. There's a big difference. Functions that are reentrant are automatically thread-safe, but thread-safe functions can still deadlock (or worse) if called again from the same thread they're already running in (for example from a signal handler).

[R.. GitHub STOP HELPING ICE]

Here are some more references: opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html and opengroup.org/onlinepubs/9699919799/functions/flockfile.html see especially in the latter: "All functions that reference (FILE *) objects shall behave as if they use flockfile() and funlockfile() internally to obtain ownership of these (FILE *) objects."

[nos]

Posix differs between thread safety, reentrancy and async signal safe. FILE* functions are not async signal safe.

[j riv]

I tend to think that practically what's going on is that it is common sense that printf is safe since it basically writes to stdout as its only 'thread safety critical' job and that'd be funny to be unsafe since utilities that run stdout with a bulldozer run simultaneously on all systems [if you find a system that doesn't, good luck in running anything].

[R.. GitHub STOP HELPING ICE]

@Lela: that line of thinking is incorrect, but your conclusion is still right.

[j riv]

'practically what's going on'

[R.. GitHub STOP HELPING ICE]

No, @Lela, it's completely incorrect thinking. Thread-safety of a process-local data structure is completely unrelated to other programs running on the same system. Processes do not share their variables with each other. You also seem to be confused that stdout is a single file/device which all processes share, whereas in reality it's rare that multiple programs share the same open file description for stdout unless one is sleeping waiting for another to terminate, or simply not using stdout.

[caf]

@Lela Dax: The "thread safety critical" job that you're missing is the manipulation of the stdout buffer, which is internal to the process but shared between threads.