Is std::ifstream thread-safe & lock-free?

Question

I intend to perform opening for reading a single file from many threads using std::ifstream. My concern is if std::ifstream is thread-safe & lock-free?

More details:

1. I use g++ 4.4 on Ubuntu & Windows XP, 4.0 on Leopard.
2. Each thread creates its own instance of std::ifstream

Libnah

In my experience, if you want to read the same file from multiple threads, say the ifstream. Then reading will affect the read pointer (result of tellg()). So you cannot do multi-thread reading on the same ifstream object. But you can create multiple ifstream objects on the same file (say foo.txt). Then each thread will have their own independent file read pointers. For writing from multiple threads, you must do your own synchronization with the available synchronization tools such as mutex and atomic variable. – Constable

Answer 1

See http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_concurrency.html.

As of the writing of that manual page, GCC's standard library defers to the operating system's C stdio file buffering. They avoid keeping state outside the C FILE structure and achieve some level of safety through it.

Since the C stdio library implements a buffer of a single range within the file around the last I/O operation, I don't see how a lock-free implementation is possible. The operations on a file must be processed serially. Perhaps unbuffered mode could help; that's a little more research than I'd like to do right now.

Inexistent

It's important to note that in the world of concurrency, lock-free is a "stronger"/stricter concept than thread-safety. – Libnah

How to verity that there is no single global I/O lock on the file opened purely for reading? – Libnah

@Viet: You need to check your OS documentation. Thanks for explaining that lock-free is a particular term, en.wikipedia.org/wiki/Lock-free. I think that most if not all C stdlib implementations will implement a lock per file in the course of buffering. It sounds like you want to implement your own buffering atop an unbuffered, hopefully lock-free, OS interface. – Inexistent

Answer 2

That is implementation defined. Standard C++ says absolutely nothing about threading, and therefore any assumptions about threads inherently invoke unspecified or implementation defined behavior.

We need the platform you are using to be more specific, but it's probably unreasonable to assume ifstream is either thread safe or lock free. If nothing else, there are probably locks involved in the OS level calls that actually do the reading from the file, in which case no true lock-free implementation is possible. Even without that, each read from an ifstream needs to check several format flags, and needs to update the flags bits depending on what occurs during the read. (i.e. istream::good() and istream::operator bool) Since there is no way all of that can be done atomicly, it's unreasonable to assume much about istream's thread safety characteristics.

Boris

"any assumptions about threads inherently invoke undefined behavior" Eh, I would think it merely means unspecified or implementation defined. – Rectangular

@GMan: Any idea about the g++ 4.4 & g++ 4.0 implementations? – Libnah

@GMan: What's the difference? – Boris

@Billy "unspecified" behavior and "implementation defined" behavior mean that the operation must have some consistent result, although that result may differ between compilers (and in the case of "implementation defined", the compiler documentation must describe the expected result). "undefined behavior" on the other hand, means that the result may be unpredictable, inconsistent, and possibly bizarre, even on a single compiler or even within one execution of a program. – Scolopendrid

@GMan: Well, technically, I suppose it is undefined. The standard doesn't require sane, consistent or well-defined results when you have multiple threads of execution. The standard literally does not define what should happen. Of course, in practice, the outcome is always well-defined by the implementation, but from a pure standards point of view, I can't see why it isn't undefined. – Casias

@jalf: Hm, I'll buy that argument. So, undefined but by the nature of threads (being very implementation-specific), the behavior is implementation-defined. – Rectangular

Answer 3

All std libraries are thread safe but not "async" safe. So you can call the same functions from different threads but not on the same objects.

Palladic

Err.. if you can't read from multiple threads than that is not thread safe. – Boris

Treating "thread safe" as a simple boolean condition applying to an entire library is a bit silly. For instance, is a file library threadsafe if two threads can write at the same time to the same file, and the library merely guarantees that all bytes written end up in the file ? A reasonable result in the presence of buffering, after all. – Section