2

The title is the question: when a thread exits, does its cached memory get flushed to the main memory?

I am wondering because cases are common where the main thread creates some threads, they do some work on independent parts of the array (no data dependencies between each other), the main thread joins all the worker threads, then does more calculations with the array values that result from the worker threads computations. Do the arrays need to be declared volatile for the main thread to see the side-effects on it?

user3286380
  • 574
  • 4
  • 10
  • Which programming language are you using? Note that the behaviour is usually defined by the programming language, independent of the operating system and hardware architecture. – nosid Mar 07 '14 at 07:23
  • @nosid I am using pthreads and C. – user3286380 Mar 07 '14 at 14:25
  • The CPU memory cache generally has no notion of threads - if it was written into the cache, it will be flushed out to lower cache levels and main memory eventually, unless process teardown or something of a similar sort invalidates those cache lines first. – twalberg Mar 07 '14 at 16:22
  • @twalberg yes, but the OS has a notion of threads. I am wondering if the OS will cause the cache to flush when a thread ends, so that its modifications to memory can be seen by other threads. caf seems to have answered my question though. – user3286380 Mar 09 '14 at 18:18

2 Answers2

1

The pthreads specification requires that pthread_join() is one of the functions that "synchronizes memory with respect to other threads", so in the case of pthreads you are OK - after pthread_join() has returned, the main thread will see all updates to shared memory made by the joined thread.

caf
  • 233,326
  • 40
  • 323
  • 462
0

Assuming you are doing this in C, and if the array is global or you have passed a structure to the threads which contains the indices on which the threads need to do the computation on and a pointer to the array, then the array need not be volatile for the main thread to see the changes since the array memory is shared between the worker threads and the main thread.

StackSmasher
  • 359
  • 1
  • 3
  • 6
  • "because the memory is shared between the worker threads and the main thread" applies to the single-variable case as well but it _does_ need volatile. Why not an array? – user3286380 Mar 07 '14 at 14:26
  • By using volatile, you instruct the compiler not to do any optimizations on that variable because some other hardware or thread might change the value. While over here,it is mentioned that threads would work on independent parts of the array.Eg:if your array is indexed from say 1-100, and you have 10 threads performing operations on 1-10, 11-20...91-100 respectively then these threads will not affect each other.It will work fine(as long as distribution of array is proper).I don't understand why do you want to prevent compiler optimization in this case by using volatile? could you elaborate? – StackSmasher Mar 07 '14 at 17:12
  • @knuckle_ball: Your mixing up _volatile_ and _atomic_. The following question is about C++, but the same is true for C. http://stackoverflow.com/questions/8819095/concurrency-atomic-and-volatile-in-c11-memory-model – nosid Mar 08 '14 at 17:43