3

I know in Java visibility of a member is not guaranteed when accessing it from another thread.

The meaning is the accessing thread will maybe see a stole value of the member (becuase the cache has not been flushed to main memory yet).

I wonder if that is the case for C++ too? (also in C++11?)

If so, how do you solve this problem in C++? (In Java, you can use the synchronized keyword).

user1028741
  • 2,745
  • 6
  • 34
  • 68

3 Answers3

2

You can use std::atomic<T> as type of the member. This guarantees a set of atomic operations, like fetch and increment. This is general much better than adding a mutex, as these operations are implemented with special atomic instructions of the CPU

ragazzojp
  • 477
  • 3
  • 14
  • 1
    As I understood atomic will guarantee the variable atomicity (you cannot interrupt it's get() or load() in the middle of the operation). But does it really ensure visibility?? Furthermore, if I want a whole object to be visible to the other threads? What do I do then?? – user1028741 Apr 01 '14 at 23:55
  • I don't fully understand what you mean. If "visibility from other thread" means that those thread can read/write (or perform additional atomic operations) on those variables without any other locking or special mechanism, then yes, `std::atomic` is designed for that. – ragazzojp Apr 01 '14 at 23:58
  • For the whole object case, you should add a mutex or some `std::atomic` members in that object, so concurrent access to its variables and methods doesn't create problems. – ragazzojp Apr 01 '14 at 23:59
  • What I meant is that I think it will still be dangerous. The other thread calling the atomic variable's get() method would maybe see a stole value of it. Am I wrong? – user1028741 Apr 02 '14 at 00:01
  • Mmm no, it's designed to be used easily. Unless you do: int x = m_atomic; x++; m_atomic = x, that is a manual increment that can be interrupted, it's safe. You can access the variable normally. – ragazzojp Apr 02 '14 at 00:04
1

Visibility of threads is a general problem with threads and not with language. In C++ visibility problems are due to bad logic, which is a code that may run without any issues without implementing a Mutex to the resource or value being accessed, if the logic is valid then the code will compile and run without any problems but the values expected may not be what you wanted.

To solve it you used a Mutex object and lock the variable being accessed. But C++11 tackles this problem even further with std::atomic. The atomic variable is a flag that encapsulates the Mutex behavior and frees you from calling lock and unlock.

Claudiordgz
  • 3,023
  • 1
  • 21
  • 48
  • As I understood atomic will guarantee the variable atomicity (you cannot interrupt it's get() or load() in the middle of the operation). But does it really ensure visibility?? Furthermore, if I want a whole object to be visible to the other threads? What do I do then?? – user1028741 Apr 01 '14 at 23:55
  • you can implement two different methods, and in another method run both threads, the methods can use a global object, furthermore, you can encapsulate all of the (even both threads) in another object. – Claudiordgz Apr 02 '14 at 01:17
0

C++ (not 11) doesn't support concurrency natively, it's provided by extensions. The two I primarily use are OpenMP and pthreads. The visibility and atomicity of things are based on what extension you're using.

  • OpenMP uses #pragma omp barrier to synchronise threads. It also has 'directives' such as atomic and critical to limit access on things.
  • pthreads synchronises on certain functions, see section 4.11 of this page to see which functions cause synchronisation. Pretty much: if you use a mutex you're fine.
  • For C++11 see the bottom of this page, you may find something useful there but I haven't worked enough with C++11 concurrency to say much.

The key point is, synchronicity is based on the multi-threading extension you're using.

In addition to the above if you're doing scientific work there's OpenMP which has all data transfer between threads explicit and so has no such worries.

Cramer
  • 1,785
  • 1
  • 12
  • 20