🔒 Locked

The problem with multithreading

Started by Russell Dec 20, 2001 at 2:42 PM 2 replies 250+ views

Original Post

Dec 20, 2001 at 2:42 PM

I have a question regarding what the problem with multithreading is, and more specifically, what the problem with sharing data between threads is. Is the problem that two threads might access the same data simultaneously, causing a problem? I don''t see how this is even possible on a single processor system, since the processor can really only execute one instruction at a time. Or... Is the problem that, for example, you might delete the last element of a linked list in one thread, and before you can set the previous element''s next pointer to NULL, another thread tries to do a theNode->next, which works fine, since the next pointer hasn''t been set to NULL, but gives you undefined behavior since the node has really been deleted? The reason I''m asking is because I want to know if it''s ok to share simple data between threads, such as a global boolean value to tell a thread whether or not it should continue running. In this case of using a global boolean, on a single processor that data will never be able to be accessed simultaneously (at least that''s what I''m thinking), so there should be no problem with data sharing in this case, right? And how about on a multi-processor system? Is sharing simple data such as a global boolean ok? I would think that it might be possible for the two processors to attempt to access the same data simultaneously in this situation and cause a problem. Thanks for your help. Russell

Neophyte

Dec 20, 2001 at 3:45 PM

One of the problems with sharing data between threads is that operations that the cpu is not able to change data in memory, but has to copy it to registers first, thus making synchronization-errors possibly between threads.
Consider the following:
You have two threads, that share an int i.
They both at some point execute the command
i = i + 1;
"simultaneously" (it''s not, as you rightly pointed out, really simultaneous).
Now, in order for the cpu to do this for one thread it does the following steps (pseudo-code):
1) Load the value stored at address into a register
2) Increase the value in the register by 1
3) Copy the value of the register back to address [i]

With multi-threading you have no control over when a different thread starts executing, and it''s possible that thread 1 is interrupted after step 1 above, then thread 2 runs all three steps, and then thread 1 finishes. Which will lead to the following:

(Assuming that i is 10 at start)

Thread 1: Loads value of i into register A (A is now 10)
Thread 2: Loads value of i into register B (B is now 10)
Thread 2: Increases value in B with 1 (B is now 11)
Thread 2: Copy value in B into i (i is now 11)
Thread 1: Increases value in A with 1 (A is now 11)
Thread 1: Copy value in A into i (i is now 11)

In other words, the value of i (starting at 10) is incremented twice, but is still only 11.

And this was an inanely simple example. Imagine what may happen when you start doing graphics, or input, or networking or whatever, and these things happen.

So, as a general rule, if you have shared data between threads always use some synchronization-method (mutexes and so on) to protect it.
It may not be necessary to do so if only 1 thread ever changes the data, but you should probably still do it.

Hope that clears things up a little.

-Neophyte

P.S With multiple processors synchronization can get *really* hairy.

Shannon Barber

Mod

368

Shannon Barber

Dec 20, 2001 at 7:06 PM

quote:
Original post by Russell
Is the problem that two threads might access the same data simultaneously, causing a problem? I don''t see how this is even possible on a single processor system, since the processor can really only execute one instruction at a time.

Reading data ''simutaneously'' is never a (software) problem - not even on MP machines.

quote:

Is the problem that, for example, you might delete the last element of a linked list in one thread, and before you can set the previous element''s next pointer to NULL, another thread tries to do a theNode->next, which works fine, since the next pointer hasn''t been set to NULL, but gives you undefined behavior since the node has really been deleted?

Precisely!

quote:

The reason I''m asking is because I want to know if it''s ok to share simple data between threads, such as a global boolean value to tell a thread whether or not it should continue running. In this case of using a global boolean, on a single processor that data will never be able to be accessed simultaneously (at least that''s what I''m thinking), so there should be no problem with data sharing in this case, right?

If only one thread writes/changes the a register sized value, and all the others only read, it''s called atomic syncronization, because it''s physically impossible for the others threads to read the value while the data is being updated (even on MP machines). If it''s a _structure this isn''t true and access must be syncronized. Atomic sync only works on 32bit sized variables on 32bit machines (16bit on 16bit machines, etc...).

quote:

And how about on a multi-processor system? Is sharing simple data such as a global boolean ok? I would think that it might be possible for the two processors to attempt to access the same data simultaneously in this situation and cause a problem.

The MP bus controller is suppose to handle this contention, and one processor will stall (for about 10ns) if this situation ever occurs. For one boolean it''ll work just fine.

What you can''t do, is change the value from two threads, or access structures (and classes) without using syncronization - mutexes, critical sections, semaphores, and events.

You can eliminate the polling by using an event, but if it''s a game loop, your going to poll it either way.

Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

"What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.