Atomic operations in Win32
-
Is reading/writing a 32-bit integer on Win32 guaranteed to be atomic ? I could not find that information anywhere. wbr Brainley
-
Is reading/writing a 32-bit integer on Win32 guaranteed to be atomic ? I could not find that information anywhere. wbr Brainley
Ok, sometimes i'm posting over-eagerly. Here is the solution : Interlocked Variable Access[^] In short : the answer is yes. wbr Brainley
-
Is reading/writing a 32-bit integer on Win32 guaranteed to be atomic ? I could not find that information anywhere. wbr Brainley
No. See here[^] for information on how to do it safely. If your programming x86 machine code you could also look up the lock prefix[^].
Steve
-
No. See here[^] for information on how to do it safely. If your programming x86 machine code you could also look up the lock prefix[^].
Steve
I'm writing a procedure where two values, wich always make up a pair, can be changed from one thread, but read from many. I only want to make shure that a read-operation always returns a valid pair (writing is actually limited by a CRITICAL_SECTION). So i use a checksum. The thread reads the variables and then checks the sum against a checksum. If one of the values got changed somewhere in between, the checksum will not match and it will try again. This works, since simple read/write operations on 32-bit Integers are atomic on 32-bit systems. I chose this way because it is much faster that using a lock mechanism, since write operation happen a lot less often (> factor 20) than write-operations.
-
I'm writing a procedure where two values, wich always make up a pair, can be changed from one thread, but read from many. I only want to make shure that a read-operation always returns a valid pair (writing is actually limited by a CRITICAL_SECTION). So i use a checksum. The thread reads the variables and then checks the sum against a checksum. If one of the values got changed somewhere in between, the checksum will not match and it will try again. This works, since simple read/write operations on 32-bit Integers are atomic on 32-bit systems. I chose this way because it is much faster that using a lock mechanism, since write operation happen a lot less often (> factor 20) than write-operations.
How can it get changed if only one thread ever changes it? How can you be sure it doesn't get changed while computing the checksum? Is a critical section really that slow?
"Great job, team. Head back to base for debriefing and cocktails." (Spottswoode "Team America")
-
How can it get changed if only one thread ever changes it? How can you be sure it doesn't get changed while computing the checksum? Is a critical section really that slow?
"Great job, team. Head back to base for debriefing and cocktails." (Spottswoode "Team America")
Here a scenarion. Thread A reads, Thread B writes, the pair consists of V1 and V2 of type int. A reads V1 B writes V1 B writes V2 A reads V2 So now A has a pair that does not belong together. Now consider this : A reads V1 B writes Checksum V1+V2 B writes V1 B writes V2 A reads V2 A checks the Sum -> does not match, so A tries the read again. There are a lot more cases, but they all work out. Using a CRITICAL_SECTION or any other kind of synchronization would mean traps into the OS and context-switches on the wait-operations. In cases where such an optimistic approach is possible, that means the probability of an error, and thus a second or even third read is very low, the performance is higher this way.
-
Here a scenarion. Thread A reads, Thread B writes, the pair consists of V1 and V2 of type int. A reads V1 B writes V1 B writes V2 A reads V2 So now A has a pair that does not belong together. Now consider this : A reads V1 B writes Checksum V1+V2 B writes V1 B writes V2 A reads V2 A checks the Sum -> does not match, so A tries the read again. There are a lot more cases, but they all work out. Using a CRITICAL_SECTION or any other kind of synchronization would mean traps into the OS and context-switches on the wait-operations. In cases where such an optimistic approach is possible, that means the probability of an error, and thus a second or even third read is very low, the performance is higher this way.
The spin count on a CS object can be utilitized to handle situations like this, but you really need to be on a multi-CPU/multi-core machine to really make use of it. If the CS is released during the spin count, no context-switch will take place. Given that simple operations are being done, I would bet that you would hit that situation more often than not. Peace!
-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles -
The spin count on a CS object can be utilitized to handle situations like this, but you really need to be on a multi-CPU/multi-core machine to really make use of it. If the CS is released during the spin count, no context-switch will take place. Given that simple operations are being done, I would bet that you would hit that situation more often than not. Peace!
-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFilesI just hijacked the thread for my own personal learnin'... Can you explain what the heck you're talking about? :) *edit* Google is my friend: Critical Section Objects[^] :rolleyes: Thanks! Mark
"Great job, team. Head back to base for debriefing and cocktails." (Spottswoode "Team America")
-
I'm writing a procedure where two values, wich always make up a pair, can be changed from one thread, but read from many. I only want to make shure that a read-operation always returns a valid pair (writing is actually limited by a CRITICAL_SECTION). So i use a checksum. The thread reads the variables and then checks the sum against a checksum. If one of the values got changed somewhere in between, the checksum will not match and it will try again. This works, since simple read/write operations on 32-bit Integers are atomic on 32-bit systems. I chose this way because it is much faster that using a lock mechanism, since write operation happen a lot less often (> factor 20) than write-operations.
Looks like you should do some research on "readers writer locks".
Steve