[interprocess] Atomic read and write.
Hello, this may be a silly question, but I have been wondering what the atomic read and write primitives are actually supposed to do? I mean, from the readers or writers POV a read or write is always atomic, isn't it? Am I missing something very obvious here? Thanks, Markus
Markus Schöpflin escribió:
Hello,
this may be a silly question, but I have been wondering what the atomic read and write primitives are actually supposed to do?
I mean, from the readers or writers POV a read or write is always atomic, isn't it? Am I missing something very obvious here?
In some architectures, a 32 read might not be atomic (even if the read is aligned). I think that Intel system is always atomic. They are there for completeness, to support systems where read or write might not be atomic.
Thanks, Markus
Regards, Ion
Ion Gaztañaga schrieb:
Markus Schöpflin escribió:
Hello,
this may be a silly question, but I have been wondering what the atomic read and write primitives are actually supposed to do?
I mean, from the readers or writers POV a read or write is always atomic, isn't it? Am I missing something very obvious here?
In some architectures, a 32 read might not be atomic (even if the read is aligned). I think that Intel system is always atomic. They are there for completeness, to support systems where read or write might not be atomic.
Sorry for being dense, but what exactly do you mean when you say a read might not be atomic? Are you thinking of memory barriers here? Or is it something else? Is there somewhere a definition of what atomic exactly means here? I'm asking because I'm currently evaluating how much of work it would be to make interprocess work on Tru64. Markus
On 10/10/07, Markus Schöpflin <markus.schoepflin@web.de> wrote:
Ion Gaztañaga schrieb:
Markus Schöpflin escribió:
Hello,
this may be a silly question, but I have been wondering what the atomic read and write primitives are actually supposed to do?
I mean, from the readers or writers POV a read or write is always atomic, isn't it? Am I missing something very obvious here?
In some architectures, a 32 read might not be atomic (even if the read is aligned). I think that Intel system is always atomic. They are there for completeness, to support systems where read or write might not be atomic.
Sorry for being dense, but what exactly do you mean when you say a read might not be atomic? Are you thinking of memory barriers here? Or is it something else? Is there somewhere a definition of what atomic exactly means here?
I believe he is referring to cache coherency - on x86 and x64, read and write are always atomic in the sense that a read will never see half of the old value and half of a write. -- Cory Nelson
Cory Nelson schrieb:
On 10/10/07, Markus Schöpflin <markus.schoepflin@web.de> wrote:
Ion Gaztañaga schrieb:
Markus Schöpflin escribió:
Hello,
this may be a silly question, but I have been wondering what the atomic read and write primitives are actually supposed to do?
I mean, from the readers or writers POV a read or write is always atomic, isn't it? Am I missing something very obvious here? In some architectures, a 32 read might not be atomic (even if the read is aligned). I think that Intel system is always atomic. They are there for completeness, to support systems where read or write might not be atomic. Sorry for being dense, but what exactly do you mean when you say a read might not be atomic? Are you thinking of memory barriers here? Or is it something else? Is there somewhere a definition of what atomic exactly means here?
I believe he is referring to cache coherency - on x86 and x64, read and write are always atomic in the sense that a read will never see half of the old value and half of a write.
So it's not an issue of memory barriers, but of a hardware not being able to serialize concurrent r/w access to the same location (either register or memory address)? Markus
Markus Schöpflin escribió:
So it's not an issue of memory barriers, but of a hardware not being able to serialize concurrent r/w access to the same location (either register or memory address)?
Yes. With 32 bits there is no problem for current architectures, but imagine we have a library for atomic 64 bit integers. Raw read and write would not be atomic in 32 architectures because memory read/write would be implemented with two memory accesses. We must also make sure that cache and other issues maintain the atomicity. I'm not an atomic operation expert (even not a beginner). Functions were inspired by apache portable runtime atomics, and there atomic read and writes were wrapped. I just followed the example because I know that 32bit operations were atomic in Intel32 but I also know that there are systems (surely as used as Intel) that have not this property.
Markus
Regards, Ion
Ion Gaztañaga schrieb:
Markus Schöpflin escribió:
So it's not an issue of memory barriers, but of a hardware not being able to serialize concurrent r/w access to the same location (either register or memory address)?
Yes. With 32 bits there is no problem for current architectures, but imagine we have a library for atomic 64 bit integers. Raw read and write would not be atomic in 32 architectures because memory read/write would be implemented with two memory accesses. We must also make sure that cache and other issues maintain the atomicity.
OK, I think I understand now. Thank you and thanks to Daniel, who has been answering me in private mail. I'll try to figure out whether Alpha hardware has this kind of atomicity build-in or whether it needs some special instructions for it. Another question: the atomic compare and swap operation as described in the header file returns the old value of the memory location. CXX provides CAS as a primitive, but it doesn't return the old value, it simply returns true/false if the CAS has succeeded/failed. I have checked the usage of CAS in the interprocess library, and it looks like you don't actually need the return value of the CAS function, besides checking that the operation has succeeded. Am I right? Would you consider changing the interface for CAS to allow the usage of a compiler primitive which doesn't provide the value of the memory location?
I'm not an atomic operation expert (even not a beginner). Functions were inspired by apache portable runtime atomics, and there atomic read and writes were wrapped. I just followed the example because I know that 32bit operations were atomic in Intel32 but I also know that there are systems (surely as used as Intel) that have not this property.
The header still contains the Apache license, I'm wondering if you simply can dual license it like you did? And isn't there a requirement that only boost licensed libraries are OK? Thank you for your help, Markus
Markus Schöpflin:
Sorry for being dense, but what exactly do you mean when you say a read might not be atomic? Are you thinking of memory barriers here? Or is it something else? Is there somewhere a definition of what atomic exactly means here?
Atomic means that when you read the value, you get back either the initial value, or one of the values that have been written (by the abstract machine) so far, even in the presence of data races. Atomicity by itself is rarely useful without acquire/release guarantees, so memory barriers are definitely part of the same story.
participants (5)
-
Cory Nelson -
Ion Gaztañaga -
Markus Schöpflin -
Markus Schöpflin -
Peter Dimov