diff options
Diffstat (limited to 'manual')
| -rw-r--r-- | manual/stdio.texi | 17 |
1 files changed, 9 insertions, 8 deletions
diff --git a/manual/stdio.texi b/manual/stdio.texi index 19a84a4e4c..40f73f4223 100644 --- a/manual/stdio.texi +++ b/manual/stdio.texi @@ -553,11 +553,11 @@ Now that we covered why it is necessary to have these locking it is necessary to talk about situations when locking is unwanted and what can be done. The locking operations (explicit or implicit) don't come for free. Even if a lock is not taken the cost is not zero. The operations -which have to be performed require memory operations which are save in +which have to be performed require memory operations that are safe in multi-processor environments. With the many local caches involved in such systems this is quite costly. So it is best to avoid the locking -completely if it is known that the code using the stream is never used -in a context where more than one thread can use the stream at one time. +completely if it is not needed -- because the code in question is never +used in a context where two or more threads may use a stream at a time. This can be determined most of the time for application code; for library code which can be used in many contexts one should default to be conservative and use locking. @@ -566,15 +566,16 @@ There are two basic mechanisms to avoid locking. The first is to use the @code{_unlocked} variants of the stream operations. The POSIX standard defines quite a few of those and the GNU library adds a few more. These variants of the functions behave just like the functions -with the name without the suffix except that they are not locking the +with the name without the suffix except that they do not lock the stream. Using these functions is very desirable since they are potentially much faster. This is not only because the locking operation itself is avoided. More importantly, functions like @code{putc} and @code{getc} are very simple and traditionally (before the introduction of threads) were implemented as macros which are very fast -if the buffer is not empty. With locking required these functions are -now no macros anymore (the code generated would be too much). But these -macros are still available with the same functionality under the new +if the buffer is not empty. With the addition of locking requirements +these functions are no longer implemented as macros since they would +would expand to too much code. +But these macros are still available with the same functionality under the new names @code{putc_unlocked} and @code{getc_unlocked}. This possibly huge difference of speed also suggests the use of the @code{_unlocked} functions even if locking is required. The difference is that the @@ -639,7 +640,7 @@ in @file{stdio_ext.h}. This function is especially useful when program code has to be used which is written without knowledge about the @code{_unlocked} functions -(or if the programmer was to lazy to use them). +(or if the programmer was too lazy to use them). @node Streams and I18N @section Streams in Internationalized Applications |