In solaris when I attached dbx to one of the running stacks, I found the call to fwrite leading to __lll_lock_wait()?
In what scenario will this happen? Does fwrite internally tries to acquire a lock?
+2
A:
the standards that I looked through (C99 and POSIX) do say nothing about locked or unlocked IO concerning fwrite.
On my linux system their is a not very precise mentioning of locking in the man page:
For non-locking counterparts, see unlocked_stdio(3).
and effectively, there is a fwrite_unlocked function. Standard unlocked functions in POSIX are only getc_unlocked(), getchar_unlocked(), putc_unlocked(), and putchar_unlocked().
My interpretation is that probably all buffered IO in the man(3) set is locked, and that you only have very few standardized interfaces to do unlocked IO.
That these things lock between threads is really a good thing since otherwise you could have completely messy output when several threads write to stderr, e.g.
Jens Gustedt
2010-09-10 14:10:09
It's not a good thing, because the granularity of locking is only at the byte level. That is, if you write strings or binary block data from two threads to the same file at the same time, it could come out with random interleaving. In practice most implementations will wrap the lock around the whole larger operation, but they're not required to and correct code cannot depend on them doing so. So the locking is nearly useless. It protects from memory corruption if multiple threads use the same file at the same time, but doing so was a **bug** already anyway.
R..
2010-09-10 16:19:20
@R. with the good thing I meant for the principle, that there is locking at all. I still remember that on the IRIX (which was not really POSIX compliant) parallel thread spit everything completely interleaved on a common output stream. But you are right, the way that it is done may be subject to criticism.
Jens Gustedt
2010-09-10 17:54:04
POSIX describes the locking fairly precisely in the `flockfile` reference page. All stdio functions except the `_unlocked` ones must perform `flockfile`/`funlockfile` equivalents internally.
jilles
2010-09-10 21:25:03
@jilles: right, thanks. What a pity that they don't crossref this on the `fwrite` page. Also on the page for `stdio.h` I see now that all of this is an optional feature in POSIX.
Jens Gustedt
2010-09-10 22:10:01
@R..: The same file, or the same `FILE*`? The 2 are quite different. For simultaneous write()s to the same file, "interleaving" is more likely to occur at the sector buffer level in the kernel, or in atomic copies to VFS buffers. Interleaving in this situation I don't think will occur at `char` granularity.
Matt Joiner
2010-09-12 08:52:26
In the MSVCRT, all `FILE*` operations are locked. The `*_unlocked` variants are provided without locks. Just to clarify, all stdio "locks" in all implementations are for the purposes of preventing corruption of the `FILE` internals, and have nothing to do with the way the OS handles IO.
Matt Joiner
2010-09-12 08:54:53
@Matt: I meant the same `FILE *`. See POSIX section 2.5 Standard I/O Streams: "All input takes place as if bytes were read by successive calls to fgetc(); all output takes place as if bytes were written by successive calls to fputc()." This makes it very clear that, as far as the spec is concerned, locking is per-byte and there is no safety against interleaved output.
R..
2010-09-12 14:51:29