C - Can global pointers be modified by different threads?

Question

Do global pointers have a scope that exist between threads?

For instance, suppose I have two files, file1.c and file2.c:

file1.c:

uint64_t *g_ptr = NULL;

modify_ptr(&g_ptr) { 
    //code to modify g_ptr to point to a valid address 
}

read_from_addr() {
    //code which uses g_ptr to read values from the memory it's pointing to
}

file2.c:

function2A() {
    read_from_addr();
}

So I have threadA which runs through file1.c and executes modify_ptr(&g_ptr) and also read_from_addr(). And then threadB runs, and it runs through file2.c executing function2A().

My question is: Does threadB see that g_ptr is modified? Or does it still see that it's pointing to NULL?

If that's not the case, what does it mean for a pointer to be global? And how do I ensure that this pointer is accessible between different threads?

Please let me know if I need to clarify anything. Thanks

Answer 1

My question is: Does threadB see that g_ptr is modified? Or does it still see that it's pointing to NULL?

Maybe. If accessed without any sort of external synchronization, you're likely to see bizarre, highly non-reproducible results -- in certain cases, the compiler may make certain optimizations based on its analysis of your code which can stem from assuming that a variable is not modified during certain code paths. For example, consider this code:

// Global variable
int global = 0;

// Thread 1 runs this code:
while (global == 0)
{
    // Do nothing
}

// Thread 2 at some point does this:
global = 1;

In this case, the compiler can see that global is not modified inside the while loop, and it doesn't call any external functions, so it can "optimize" it into something like this:

if (global == 0)
{
    while (1)
    {
        // Do nothing
    }
}

Adding the volatile keyword to the declaration of the variable prevents the compiler from making this optimization, but this was not the intended use case of volatile when the C language was standardized. Adding volatile here will only slow down your program in small ways and mask the real problem -- lack of proper synchronization.

The proper way to manage global variables that need to be accessed simultaneously from multiple threads is to use mutexes to protect them¹. For example, here's a simple implementation of modify_ptr using a POSIX threads mutex:

uint64_t *g_ptr = NULL;
pthread_mutex_t g_ptr_mutex = PTHREAD_MUTEX_INITIALIZER;

void modify_ptr(uint64_t **ptr, pthread_mutex_t *mutex)
{
    // Lock the mutex, assign the pointer to a new value, then unlock the mutex
    pthread_mutex_lock(mutex);
    *ptr = ...;
    pthread_mutex_unlock(mutex);
}

void read_from_addr()
{
    modify_ptr(&g_ptr, &g_ptr_mutex);
}

Mutex functions ensure that the proper memory barriers are inserted, so any changes made to a variable protected by a mutex will be properly propagated to other CPU cores, provided that every access of the variable (including reads!) is protected by the mutex.

¹⁾ You can also use specialized lock-free data structures, but those are an advanced technique and are very easy to get wrong

Answer 2

This question is the textbook example of what makes concurrent programming difficult. A really thorough explanation could fill an entire book, as well as lots of articles of varying quality.

But we can summarize a little. A global variable is in a memory space visible to all the threads. (The alternative is thread-local storage, which only one thread can see.) So you would expect that if you have a global variable G, and thread A writes value x to it, then thread B will see x when it reads that variable later on. And in general, that is true -- eventually. The interesting parts are what happens before "eventually".

The biggest source of trickiness are memory consistency and memory coherence.

Coherence describes what happens when thread A writes to G and thread B tries to read it at nearly the same moment. Imagine that thread A and B are on different processors (let's also call them A and B for simplicity). When A writes to a variable, there is a lot of circuitry between it and the memory that thread B sees. First, A will probably write to its own data cache. It will store that value for a while before writing it back to main memory. Flushing the cache to main memory also takes time: there's a number of signals that have to go back and forth on wires and capacitors and transistors, and a complicated conversation between the cache and the main memory unit. Meanwhile, B has its own cache. When changes occur to main memory, B may not see them right away — at least, not until it refills its cache from that line. And so on. All in all, it may be many microseconds before thread A's change is visible to B.

Consistency describes what happens when A writes to variable G and then variable H. If it reads back those variables, it will see the writes happening in that order. But thread B may see them in a different order, depending on whether H gets flushed from cache back to main RAM first. And what happens if both A and B write to G at the same time (by the wall clock), and then try to read back from it? Which value will they see?

Coherence and consistency are enforced on many processors with memory barrier operations. For example, the PowerPC has a sync opcode, which says "guarantee that any writes that have been made by any thread to main memory, will be visible by any read after this sync operation." (basically it does this by rechecking every cache line against main RAM.) The Intel architecture does this automatically to some extent if you warn it ahead of time that "this operation touches synchronized memory".

Then you have the issue of compiler reordering. This is where the code

int foo( int *e, int *f, int *g, int *h) 
{
   *e = *g;
   *f = *h;
   // <-- another thread could theoretically write to g and h here
   return *g + *h ;
}

can be internally converted by the compiler into something more like

int bar( int *e, int *f, int *g, int *h) 
{
  int b = *h;
  int a = *g;
  *f = b ;
  int result = a + b;
  *e = a ;
  return result;
}

which could give you a completely different result if another thread performed a write at the location given above! also, notice how the writes occur in a different order in bar. This is the problem that volatile is supposed to solve -- it prevents the compiler from storing the value of *g in a local, but instead forces it to reload that value from memory every time it sees *g.

As you can see, this is inadequate for enforcing memory coherence and consistency across many processors. It was really invented for cases where you had one processor that was trying to read from memory-mapped hardware -- like a serial port, where you want to look at a location in memory every n microseconds to see what value is currently on the wire. (That is really how I/O worked back when they invented C.)

What to do about this? Well, like I said, there are whole books on the subject. But the short answer is that you probably want to use the facilities your operating system / runtime platform provide for synchronized memory.

For example, Windows provides the interlocked memory access API to give you a clear way of communicating memory between threads A and B. GCC tries to expose some similar functions. Intel's threading building blocks give you a nice interface for x86/x64 platforms, and the C++11 thread support library provides some facilities also.

Answer 3

My question is: Does threadB see that g_ptr is modified?

Probably. g_ptr is accessed by threadB via read_from_addr(), so the same g_ptr is seen all the time. This has nothing to do with the “intramodular globalness” of g_ptr: it would work just as well if g_ptr were declared static and had internal linkage since, as you have written it here, it appears at file scope before read_from_addr().

Or does it still see that it's pointing to NULL?

Probably not. Once the assignment is made, it's visible to all threads.

The issue here is that if you have two threads accessing shared data where at least one thread is writing to it (which is the case here), you need to synchronize access to it because ordinary memory reads and writes are not atomic. In POSIX, for example, the behaviour under these circumstances is formally “undefined”, which basically means all bets are off and your machine can go rogue-o-matic and eat your cat as far as the standard is concerned.

So you will really want to use an appropriate thread synchronization primitive (e.g. a read/write lock or a mutex) to ensure a well-behaved program. On Linux with pthreads, you'll want to look at pthread_rwlock_* and pthread_mutex_*. I know that other platforms have equivalents, but I have no clue what they are.

Answer 4

global variables are available to all the threads.

For Ex:

struct yalagur
{
char name[200];
int rollno;
struct yalagur *next;
}head;

int main()
{
thread1();
thread2();
thread3();
}

now above structure is shared between all the threads.

any thread can access the structure directly.

so this is called shared memory between threads.

u need to use mutex/shared variables / etc concept to update/read/delete the shared memory.

Thanks Sada