views:

381

answers:

3

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

Thanks in advance!

A: 

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.

Charles Beattie
Err.. if you can't read from multiple threads than that is *not* thread safe.
Billy ONeal
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.
MSalters
+2  A: 

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.

Billy ONeal
"any assumptions about threads inherently invoke undefined behavior" Eh, I would think it merely means unspecified or implementation defined.
GMan
Viet
@GMan: What's the difference?
Billy ONeal
@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.
Tyler McHenry
@Tyler McHenry: Thank you :) Edited.
Billy ONeal
@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.
jalf
@jalf: Hm, I'll buy that argument. So, undefined but by the nature of threads (being very implementation-specific), the behavior is implementation-defined.
GMan
+2  A: 

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.

Potatoswatter
It's important to note that in the world of concurrency, lock-free is a "stronger"/stricter concept than thread-safety.
Viet
How to verity that there is no single global I/O lock on the file opened purely for reading?
Viet
@Viet: You need to check your OS documentation. Thanks for explaining that lock-free is a particular term, http://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.
Potatoswatter