How do scanf (), std :: cin behave in a multi-threaded environment?

Question

I want to indicate my problem using an example.

Assuming there is an array of N /*(N>>1)*/ threads that are configured to run this function:

 void Process() { //Some thread safe processing which requires in-deterministic computation time unsigned char byte; std::cin >> byte; } 

As soon as they all start simultaneously, what happens? How are concurrent calls to std :: cin handled? What does the end user who works on the console see / experience?

Edit: There is one more thing I would like to add. Is the code below safe enough to give up the idea of ​​using std: cin in only one (possibly main) thread?

 void Process() { //Some thread safe processing which requires in-deterministic computation time //Mutex lock unsigned char byte; std::cin >> byte; //Mutex unlock } 

Answer 1

Pre C ++ 11, it depends on the implementation; at least one implementation guaranteed call synchronization. (VC ++ guarantees std::cout synchronization, but not for other iostream objects. G ++ offers the same guarantees as C ++ 11, even in earlier versions of the compiler.) In C ++ 11, this is clearly undefined.

The general rule is simple: any modification of the state of an object in any thread requires that all calls be synchronized. And all >> operators on std::istream are considered to change its state.

In general, for any given thread, it is probably good to use it in only one thread. (There are exceptions, such as logging flows, where the logging object provides security flow.) This is especially true for input, because even when synchronized from the outside, the sequence of statements will usually not be specified if they are in separate streams. So even with synchronization, if your user enters "ab" , which thread receives 'a' and which receives 'b' in your example will be undefined.

EDIT:

There seem to be special rules for standard stream objects ( std::cin , std::cout , etc.). Parallel access is guaranteed not to race data, at least in some cases. This can lead to confusion of characters, i.e. If you enter int (and not just one character) and your user inputs "123 89\n" , there is a chance that thread 1 will see "1389\n" and thread 2 "2 " , which will not give you consistent results.

My global recommendation is worth it. I cannot imagine any realistic case where alternating characters would not pose a problem. (Also, I don't think I ever wrote code that actually inputs from std::cin ; it is always from std::istream& , which may be std::cin , or may be a file.)

Answer 2

I would say that the result is not predictable without mutexes.

If you use a mutex, everything is fine. For what mutexes.

Answer 3

The first thread uses std :: cin to block it (unless you use sync_with_stdio(false) ). That way you don't need a mutex. http://en.cppreference.com/w/cpp/io/cin Anyway, I do not recommend using it in a multi-threaded application. The problem is that there is no way to interrupt cin from another thread.