0

I'm creating a simple server which stores several variables globally. On occasion these variables will update and during this time the variables are locked from other threads. Each client who accesses the server is granted their own thread, but has no way to change these variables and are essentially readonly. My question to the internet is do I need to worry about either a) two threads reading the same variable at the same time (not changing) or b) the writing the variable process interrupting the reading process.

I know that in most cases writing a double is not an atomic operation because it is usually more than one register, but can the reading operation be interrupted?

Thanks

AzureX
  • 71
  • 1
  • 4
  • 3
    What architecture (x86, AMD64, etc.)? – Matthew Flaschen Jun 30 '10 at 08:20
  • 2
    The answer to "Is (doing anything but calling synchronization primitives) an atomic operation in (anything)?" is usually "No." – P Shved Jun 30 '10 at 08:31
  • possible duplicate of [Is Updating double operation atomic](http://stackoverflow.com/questions/1292786/is-updating-double-operation-atomic) – Suma Jun 30 '10 at 08:38
  • 4
    @Pavel: most single operations on word-sized data is generally atomic on most CPU's. Of course, that doesn't mean it's thread-safe (reordering issues can still wreck everything), but reading or writing an int, for example, is pretty much always atomic. – jalf Jun 30 '10 at 09:23
  • @Pavel, as far as we know, the answer to *"does life exist in (randomly selected cubic meter of the universe)"* is virtually always "no". Still, it's fun to deal with the odd-one-outs. – peterchen Jun 30 '10 at 10:12
  • @Suma: no duplicate, that's a Win32 link. Different rules. – MSalters Jun 30 '10 at 11:16
  • I still think it is duplicate, as it is CPU architecture which matters, not Win32 or Linux. No strong feelings, though, I understand your objection. – Suma Jun 30 '10 at 13:36

3 Answers3

3

My first guess is that this has nothing to do with Linux as an OS.

It is for sure related to the CPU in use, as some may be able to load/store double in memory in 1 operation. The x86 series has such an op-code for the FPU.

It may also be linked to the compiler that can make use of these CPU abilities to load/store doubles in 1 operation. Don't know what gcc does.

Didier Trosset
  • 36,376
  • 13
  • 83
  • 122
  • 1
    I think it is architecture-dependent, and OS independent. Linux does not know, care, or make any difference to the answer. – MarkR Jun 30 '10 at 09:53
  • 1
    Not that simple. It's quite possible that architectures can do only _aligned_ atomic loads; I think x86 is such a system. Then it's up to the OS and compiler to store doubles only at aligned addresses, e.g. by making sure that malloc() returns sizeof(double)-aligned addresses. – MSalters Jun 30 '10 at 11:19
2

[Edit] Apologies, I was out of it when I read this question originally and gave an incorrect answer which jalf kindly pointed out.

I know that in most cases writing a double is not an atomic operation because it is usually more than one register, but can the reading operation be interrupted?

Yes. Imagine trying to write your own IEEE double-precision floating type using two WORD-sized variables. We cannot read both of these atomically, as they are two distinct parts. One could be in the process of being modified concurrently at the same time we are trying to read.

do I need to worry about either a) two threads reading the same variable at the same time (not changing) or b) the writing the variable process interrupting the reading process.

a: no

b: yes

You'll either need to use a synchronization mechanism for the readers (in addition to the writer) or, if you're like me, just make it a WORD-sized single-precision float for the shared data which is often atomic for reading on modern systems (though you should verify this), stick to atomic operations to modify it, and avoid the headaches.

stinky472
  • 6,737
  • 28
  • 27
  • 2
    atomicity is also applicable to reading. Say you read the first word of a double, and then an (atomic) write updates the entire double, and you read the second word. That's not atomic. Reading of an `int` is typically atomic though. It happens as one operation and can never be garbled by a badly timed write. – jalf Jun 30 '10 at 09:26
  • @jalf You're right. I worded this very crudely and incorrectly. What I should have said is that, "if you are only concurrently reading and not writing, you don't have to worry about atomic operations." I will modify this post accordingly. – stinky472 Jun 30 '10 at 09:51
0

If you are only reading, you should not have to worry about atomicity. If you are reading and writing, you will need to use a mutex lock, both on your "server" and "client" thread. Locking only when writing only gets half of the job done.

Now, with a single double you may be in some luck depending on your compiler works and on your exact hardware architecture. See this answer.

Community
  • 1
  • 1
xcut
  • 6,219
  • 1
  • 33
  • 27
  • That is somewhat beside the point. of course you can make the operation atomic by explicitly locking it. Explicitly locking is a very expensive operation though, and for certain operations you can do much better without them. Atomic values are a prerequisite for such methods. – Fabio Fracassi Jun 30 '10 at 12:17
  • It would be beside the point, if the submitter had not explicitly mentioned it in his question! "On occasion these variables will update and during this time the variables are locked from other threads [...]". As far as atomic updates are concerned, the existing answer I linked to has more detail than any here. – xcut Jun 30 '10 at 14:20