Say I have a single floating point number called result equal to 0 and two threads, one thread adds 4 and the other subtracts 2. Is there any possibility that result will be equal something other then 2 afterwards?

If you want a more concrete example I ask this question because of a project I'm working on. Basically I'm simulating a network of neurons and I want to distribute the neurons among multiple threads so it runs faster.

Every thread is responsible for it's own group of neurons and at each time step of the simulation all threads calculate the voltage of their neurons and see if any neurons have exceeded a threshold, then they run into a barrier and wait for all the threads to catch up.

Then the voltages of any neurons connect to the neurons that exceeded the threshold are then added to or subtracted from depending on the strength of the connection. It's this step I worry about because two threads could try to change the voltage of the same neuron at the same time. I think I know a way around this but I wondered if things are fine the way they are, since the threads are adding or subtracting values as opposed to assigning values.

After this the threads run into the same barrier as before and wait for each other before starting the next time step.

Well you're expecting thread 1 to do this and thread 2 to do this (before or afterwards), Then all will be well.


But if it actually goes like this (or many other variations which interleave the instructions),
then you're going to have lots of very interesting Heisenbugs to deal with.

> Basically I'm simulating a network of neurons and I want to distribute the neurons among multiple threads so it runs faster.
Do you actually have a multi-core CPU?
If you don't, your statement is bogus.

You will require a semaphore to keep both threads from accessing the same data simultaneously.
Thread#1

Thread#2

Otherwise you run the risk of both simultaneously accessing the same argument.

There is only one processor that I'm aware of that will allow you to change a memory location without needing a semaphore.

add mem[reg],4

Changes memory without being pre-empted.

A semaphore with only one token, more commonly known as a 'Lock'.

I know you need a semaphore if you have two or more threads writing to a variable, but do you need them if you have one thread writing and all other threads reading?

With only one writing thread, and the others merely read, Depends on what the functionality does. Is it safe to use obsolete data!

Is only a single write operation required? Such as only writing 32-bits on a 32-bit processor?

If in either case is no, then if a standard mutex/semaphore/critical section is too slow, then a special lock is required!

If more then a single write is required then the thread can be pre-empted between a data write sequence. Also a thread can read a 32-bit value, get pre-empted by a 32-bit write and when gets released, will be working with old data! Having a locking mechanism is the safest!

It's kind of complicated, but the safest for now, is ful lock for read and write.

According to MS:
The Read method is unnecessary on 64-bit systems, because 64-bit read operations are already atomic. On 32-bit systems, 64-bit read operations are not atomic unless performed using Read.

Reference: http://msdn.microsoft.com/en-us/libr...cked.read.aspx

Therefore, 32 bit reads on 32 bit systems are atomic and don't need locking. However, adding and subtracting still needs locking. One simple way to do that in .net is using the "interlocked" class.
----
Writing is a different story and needs to be locked. An easy way to do that for simple types in .net is using interlocked.exchange

Reference: http://msdn.microsoft.com/en-us/libr....exchange.aspx

On x86 systems you can do a locked add in one instruction.

Your link to Heisenbugs doesn't exist anymore or was linked incorrectly. http://en.wikipedia.org/wiki/Unusual_software_bug