Streams can be used in multi-threaded applications in the same way they are used in single-threaded applications. But the programmer must be aware of the possible complications. It is important to know about these also if the program one writes never use threads since the design and implementation of many stream functions is heavily influenced by the requirements added by multi-threaded programming.
The POSIX standard requires that by default the stream operations are atomic. I.e., issuing two stream operations for the same stream in two threads at the same time will cause the operations to be executed as if they were issued sequentially. The buffer operations performed while reading or writing are protected from other uses of the same stream. To do this each stream has an internal lock object which has to be (implicitly) acquired before any work can be done.
But there are situations where this is not enough and there are also situations where this is not wanted. The implicit locking is not enough if the program requires more than one stream function call to happen atomically. One example would be if an output line a program wants to generate is created by several function calls. The functions by themselves would ensure only atomicity of their own operation, but not atomicity over all the function calls. For this it is necessary to perform the stream locking in the application code.
The
flockfilefunction acquires the internal locking object associated with the stream stream. This ensures that no other thread can explicitly throughflockfile/ftrylockfileor implicit through a call of a stream function lock the stream. The thread will block until the lock is acquired. An explicit call tofunlockfilehas to be used to release the lock.
The
ftrylockfilefunction tries to acquire the internal locking object associated with the stream stream just likeflockfile. But unlikeflockfilethis function does not block if the lock is not available.ftrylockfilereturns zero if the lock was successfully acquired. Otherwise the stream is locked by another thread.
The
funlockfilefunction releases the internal locking object of the stream stream. The stream must have been locked before by a call toflockfileor a successful call offtrylockfile. The implicit locking performed by the stream operations do not count. Thefunlockfilefunction does not return an error status and the behavior of a call for a stream which is not locked by the current thread is undefined.
The following example shows how the functions above can be used to
generate an output line atomically even in multi-threaded applications
(yes, the same job could be done with one fprintf call but it is
sometimes not possible):
FILE *fp;
{
...
flockfile (fp);
fputs ("This is test number ", fp);
fprintf (fp, "%d\n", test);
funlockfile (fp)
}
Without the explicit locking it would be possible for another thread to
use the stream fp after the fputs call return and before
fprintf was called with the result that the number does not
follow the word ‘number’.
From this description it might already be clear that the locking objects
in streams are no simple mutexes. Since locking the same stream twice
in the same thread is allowed the locking objects must be equivalent to
recursive mutexes. These mutexes keep track of the owner and the number
of times the lock is acquired. The same number of funlockfile
calls by the same threads is necessary to unlock the stream completely.
For instance:
void
foo (FILE *fp)
{
ftrylockfile (fp);
fputs ("in foo\n", fp);
/* This is very wrong!!! */
funlockfile (fp);
}
It is important here that the funlockfile function is only called
if the ftrylockfile function succeeded in locking the stream. It
is therefore always wrong to ignore the result of ftrylockfile.
And it makes no sense since otherwise one would use flockfile.
The result of code like that above is that either funlockfile
tries to free a stream that hasn't been locked by the current thread or it
frees the stream prematurely. The code should look like this:
void
foo (FILE *fp)
{
if (ftrylockfile (fp) == 0)
{
fputs ("in foo\n", fp);
funlockfile (fp);
}
}
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 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 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.
There are two basic mechanisms to avoid locking. The first is to use
the _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 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
putc and 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 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 putc_unlocked and getc_unlocked. This possibly huge
difference of speed also suggests the use of the _unlocked
functions even if locking is required. The difference is that the
locking then has to be performed in the program:
void
foo (FILE *fp, char *buf)
{
flockfile (fp);
while (*buf != '/')
putc_unlocked (*buf++, fp);
funlockfile (fp);
}
If in this example the putc function would be used and the
explicit locking would be missing the putc function would have to
acquire the lock in every call, potentially many times depending on when
the loop terminates. Writing it the way illustrated above allows the
putc_unlocked macro to be used which means no locking and direct
manipulation of the buffer of the stream.
A second way to avoid locking is by using a non-standard function which was introduced in Solaris and is available in the GNU C library as well.
The
__fsetlockingfunction can be used to select whether the stream operations will implicitly acquire the locking object of the stream stream. By default this is done but it can be disabled and reinstated using this function. There are three values defined for the type parameter.
FSETLOCKING_INTERNAL- The stream
streamwill from now on use the default internal locking. Every stream operation with exception of the_unlockedvariants will implicitly lock the stream.FSETLOCKING_BYCALLER- After the
__fsetlockingfunction returns the user is responsible for locking the stream. None of the stream operations will implicitly do this anymore until the state is set back toFSETLOCKING_INTERNAL.FSETLOCKING_QUERY__fsetlockingonly queries the current locking state of the stream. The return value will beFSETLOCKING_INTERNALorFSETLOCKING_BYCALLERdepending on the state.The return value of
__fsetlockingis eitherFSETLOCKING_INTERNALorFSETLOCKING_BYCALLERdepending on the state of the stream before the call.This function and the values for the type parameter are declared in stdio_ext.h.
This function is especially useful when program code has to be used
which is written without knowledge about the _unlocked functions
(or if the programmer was too lazy to use them).