2

It is a general question but:

In a multithreaded program, is it safe for the compiler to use registers to temporarily store global variables?

I think its not, since storing global variables in registers may change saved values for other threads.

And how about using registers to store local variables defined within a function?

I think it is ok,since no other thread will be able to get these variables.

Please correct me if im wrong. Thank you!

Itzik984
  • 15,968
  • 28
  • 69
  • 107
  • 1
    when you mention about "thread" you should think of shared memory model like JVM or .NET memory model. Moreover, if you save local value to registers it doesn't safe at all because registers were used by among processors. It will be complicated if you use register and never release value by saving directly to registers – cat916 Aug 10 '12 at 14:59

3 Answers3

4

Things are much more complicated than you think they are.

Even if the compiler stores a value to memory, the CPU generally does not immediately push the data out to RAM. It stores it in a cache (and some systems have 2 or 3 levels of caches between the processor and the memory).

To make things worse, the order of instructions that the compiler decides, may not be what actually gets executed as many processors can reorder instructions (and even sub-parts of instructions) in their own pipelines.

In general, in a multithreaded environment you should personally take care to never access (either read or write) the same memory from two separate threads unless one of the following is true:

  • you are using one of several special atomic operations that ensure proper synchronization.
  • you have used one of several synchronization operations to "reserve" access to shared data and then to "relinquish" it. These do include the required memory barriers that also guarantee the data is what it's supposed to be.

You may want to read http://en.wikipedia.org/wiki/Memory_ordering#Memory_barrier_types and http://en.wikipedia.org/wiki/Memory_barrier

If you are ready for a little headache and want to see how complicated things can actually get, here is your evening lecture Memory Barriers: a Hardware View for Software Hackers.

Analog File
  • 5,280
  • 20
  • 23
1

'Safe' is not really the right word to use. Many higher level languages (eg. C) do not have a threading model and so the language specification says nothing about mutli-threaded interactions.

If you are not using any kind of locking primitives then you have no guarantees what so ever about how the different threads interact. So the compiler is within its rights to use registers for global variables.

Even if you are using locking the behaviour can still be tricky: if you read a variable, then grab a lock and then read the variable again the compiler still has no way of knowing if it has to read the variable from memory again, or can use the earlier value it stored in a register.

In C/C++ declaring a variable as volatile will force the compiler to always reload the variable from memory and solve this particular instance.

There are also 'Interlocked*' primitives on most systems that have guaranteed atomicity semantics which can be used to ensure certain operations are threadsafe. Locking primitives are typically built on these low level operations.

Rob Walker
  • 46,588
  • 15
  • 99
  • 136
  • C11 and C++11 introduced a thread-aware memory model. (Where data races are undefined behaviour, exactly to allow compilers to continue to keep values in registers like they previously were.) C++ `std::atomic` and C11 `_Atomic` allow portable lock-free code, making `volatile` hand-rolled atomics obsolete. (volatile could only semi-portably give you behaviour like `memory_order_relaxed`. [When to use volatile with multi threading?](https://stackoverflow.com/a/58535118) - basically never now that C++11 exists.) – Peter Cordes Feb 23 '21 at 03:43
  • But yes, `std::atomic` does force actual access to memory, exactly like you describe, and also ordering constraints non-atomic accesses to make synchronization possible. – Peter Cordes Feb 23 '21 at 03:45
0

In a multithreaded program, you have one of two cases: if it's running on a uniprocessor (single core, single CPU), then switching between threads is handled like switching between processes (although it's not quite as much work since the threads operate in the same virtual memory space) - all registers of one thread are saved during the transition to another thread, so using registers for whatever purpose is fine. This is the job of the context switch routines that the OS uses, and the register set is considered part of a threads (or processes) context. If you have a multiprocessor system - either multiple CPUs or multiple cores on a single CPU - each processor has its own distinct set of registers, so again, using registers for storing things is fine. On top of that, of course, context switching on a particular CPU will save the registers of the old thread/process before switching to the new one, so everything is preserved.

That said, on some architectures and/or with some OSes, there might be specific exceptions to that, because certain registers are reserved by the ABI for specific uses by the OS or by the libraries that provide an interface to the OS, but your compiler(s) generally have that type of knowledge of your platform built in. You need to be aware of them, though, if you're doing inline assembly or certain other "low-level" things...

twalberg
  • 59,951
  • 11
  • 89
  • 84
  • when saving a register, is it saving its value, or the register itself? meaning which exact register? if it is the value being saved, it is ok. if it is the exact register being saved (single core single CPU), wont we get a problem? – Itzik984 Aug 10 '12 at 15:16
  • It saves the values that each register contains into a specific spot in memory so that it can be restored next time this thread is scheduled to run again. You can't really "save" a register, as it's a portion of the integrated circuit... – twalberg Aug 10 '12 at 15:21
  • i meant saving a pointer of some sort to a specific register... say i want to save a certain number in R13. from what i understand, we wont save R13, we will save 10. am i right? – Itzik984 Aug 10 '12 at 15:23
  • It will save whatever the value is in R13 - if that value in R13 is 10, then the value 10 will get put in a specific memory location to be recalled later. – twalberg Aug 10 '12 at 15:52