The Linux streams library
Streams and performance
● Since each FILE structure is held in user space
it could be accessed by two threads at the
● So the streams library locks each FILE to avoid
● You must take these locks into consideration
when designing a multi-threaded streams using
Options for design – best option
● Don't use the same stream in different threads
● If you use the standard stream operation (without
the _unlocked suffix) then you get quite good
● This is due to the fact that uncontended locks in
Linux are acquired very fast in user space (futex).
● Or, you can go a step further and just use the
*_unlocked operations and get no locking at all.
Options for design – little contention
● If your application is not doing lots of IO then you
can just go ahead and use the same streams in
different threads with little contention.
● Remember that streams buffer in user space and
so most of the time you are causing very slight
● In this case you must not use the _unlocked
versions of the functions.
Options for design – reducing
● If you do contend on streams then you can
manage the locking yourself and get some more
● Use flockfile(3) and funlockfile(3) and between
them use the *_unlocked operations.
● If you have multiple IO operations between each
lock and unlock then you are saving the need to
acquire and release the lock multiple times.
Locking manually for transactional
● If you have multiple threads that want to access the same
files using the streams library and you want each to perform
several IO operation without being interrupted then you must
resort to manual locking.
● Use flockfile(3) and funlockfile(3) and between them use the
● Note that this does not protect you from other processes
accessing the same file.
● If you put the FILE structures and their buffers (using
setbuffer) into shared memory you can use the streams
library for multi-processed designs.
● man unlocked_stdio from the Linux manual
● 'I/O on streams' from 'info libc'.