threads question

<ja************ @gmail.com> wrote...

[...]

Threads are off-topic here since C++ does not define anything thread-
related in its Standard. Try comp.programmin g.threads.

ja************@ gmail.com wrote:

assuming code:

int i=0;//global variable

//process 1 //process 2
int num=0; int num=0;
while(i<5){ while(i<5){
num=num+1; num=num+1;
i=i+1; i=i+1;
} }

what is the range of values for num?
it is supposed to be from 0-15, but i dont know why- any thoughts?

Mr. Bazarov is correct as usual, threads are not part of C++ and are
therefore off-topic in a strict sense. However, I'll answer just to
illustrate why threads are tricky in C++ (heck, any language) because
there are no threading primitives...

First, the easy case, suppose process 1 runs to completion (exits the
loop) before process 2 ever gets started. When process 2 finally
starts, i is already equal to 5 so the while loop never executes and num
remains 0.

Now, how do we get a num equal to 15?

Suppose process 1 runs first and gets to the point mid way through
executing the i = i+1 statement. It has read the value (0) of i in to a
register and is about to add 1 to it when its time slice is up and it is
interrupted.

Now process 2 runs for a while, and lets say it loops 5 times, with i
having values:

0, 1, 2, 3, 4

Then just before it can execute the i = i+1 statement, or even after it,
but before it can perform the relational test in the while loop... Its
time slice is up and process 1 runs again.

Process 1 still has the value 0 in the register, its context is
restored, and it resets i to 1 now (not 4 or 5 as process 2 had left it).

Now, in an evenly scheduled round-robin (for same priority levels)
system you'd assume that process 1 would now run to completion. But
lets assume a really pathalogical case. Maybe process 1 gets a tiny
time slice before being interrupted by a higher priority process/thread,
just enough to loop exactly once back to where it was, then the round
robin scheduler moves back to process 2 since 1 had at least some time...

Now process 2 gets to run again. It loops with i values:

1, 2, 3, 4

Before once again giving up to process 1. Now process 1 runs again,
with 1 held in the register... It has the ill fortune to loop exactly
once more... Then process 2 runs again...

2, 3, 4

Then 1, and 2...

3, 4

Then finally 1 and 2 once more...

4

So, how many iterations has process 2 actually made through its loop? 15...

Admittedly, this is an extremely pathalogical case - one that you would
probably never be able to induce during testing, but which would almost
certainly occur in the first week of client/customer use. ;-)

It also illustrates just the tip of the iceberg when it comes to the
difficulties and pitfalls associated with multithreaded programming (or
multiprocess programming with shared memory or other resources). And as
Mr. Bazarov points out, C++ has no help for you. Even programming
languages such as Java with built in threading and synchronization
primitives won't think/design for you.

Phil Staite wrote:

Mr. Bazarov is correct as usual, threads are not part of C++ and are
therefore off-topic in a strict sense. However, I'll answer just to
illustrate why threads are tricky in C++ (heck, any language) because
there are no threading primitives...

Just a touch of theory: Threads are tricky in any language - even those that
claim to support them robustly - when they violate encapsulation. One thread
would prefer to ignore and be ignored by other threads. Instead, a thread
must often use semaphores that couple its private control flow details to
other threads' details.

(BTW - question for Phil: Did you submit a Bug++ of the Month last
millenium? I thought you did, but it's Google-proof.)

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces