11

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?

Community
  • 1
  • 1
j riv
  • 3,593
  • 6
  • 39
  • 54

1 Answers1

11

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.

Huang F. Lei
  • 1,835
  • 15
  • 23
  • 8
    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 Dec 04 '10 at 13:37
  • Here are some more references: http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html and http://www.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." – R.. GitHub STOP HELPING ICE Dec 04 '10 at 13:41
  • Posix differs between thread safety, reentrancy and async signal safe. FILE* functions are not async signal safe. – nos Dec 04 '10 at 14:05
  • 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]. – j riv Dec 04 '10 at 14:44
  • @Lela: that line of thinking is incorrect, but your conclusion is still right. – R.. GitHub STOP HELPING ICE Dec 04 '10 at 15:45
  • 'practically what's going on' – j riv Dec 04 '10 at 16:40
  • 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. – R.. GitHub STOP HELPING ICE Dec 04 '10 at 17:48
  • @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. – caf Dec 06 '10 at 04:22