What would happen if 2 different threads called 1 procedure at the exact same time? nothing? would it crash? or would it continue normally?
Posted on 2002-03-09 00:32:08 by m00p
Well im very qualified, and yet not at all qualified to answer this question :grin:


What i mean is i *just* wrote midterms covering this question. But the downside is, the course is non-windows specific. The topic is OS's in general wich can include multiprocessor OS's or multiprogram OS's (like windows 9x)


So here is what i have learned (*again be warned this is only theory talking ~ can be a big diff from reality *)

The OS provides a "process" enviroment to every task (or program you decide to run). This process has many Kernal Level theads available in the form of API's to use at its disposal. All thread management is done by the "windows" black box from the programmers point of view. This is how you're use to coding as you do with API's....

However, there is API's that will allow you to "create" process threads. This means you can declair to your process that you need another user specific thread, for reasons and purposes unknown to the OS. For this reason there is NO OS support in the syncronization of USER THREAD. (however Kernal threads are all taken care of).

Now with this in mind, to answer your question:
What would happen if 2 different threads called 1 procedure at the exact same time? nothing? would it crash? or would it continue normally?


You can have two "user" threads call the same proceedure at the same time. Because in reality they are never at the same time, rather time sliced between them to seemingly act in parallel. If the function is not data specific (ie has no critical section) then you will find no problems.

If you do have a critical section, where the presence of two treads at the same point of code can change the overall behavior, then you DO need to manually provide syncronization between threads.

Example:

Proc is:

A = A +1
B= B - A

If two treads run this proc in parallel (while A and B are global varaiables), then you have a syncronization "critical section" probelm.

If one thread enter the proc with A=1, B=2:
does A=A+1 ---> A==2
then process swithces to the other thread that enters with A=0, B=4..
Does all the Proc:

A=A+1 ---> A=1
B=B+A ---> B=5

Then leaves, and the frist thread finishes out:

B=B+A ---> PROBLEM! B==5 now! not origionally 2! and A==1 not 2!!
Thus B==6 when it should have been B==4 for the first thread!!!

This is the "critical section" where no two processes can interfear with each other from "concourent threads". In this situration you need to manually provide software "traps" to ensure that if one thread is active in a critacal section, that the others can not enter till this section is released.

((( This is exactly why you need to "lock" you global memory before "using" the memory ~ you want to ensure that the data is true ~ regardless of if the HD swappes in info to this thu DMA or something )))

To avoid unwanted errors and *very had to trace* bugs, the "traps" take the form of syncronization signals and arrays managins which thread is win what proc:

Fix'd proc in general:

...
signal to other threads critical section in use
A=A+1
B=B+A
sgnal to other threads that critical section is free
...

When in use the other threads "wait" till the 'free' signal comes and allows the thread waiting to contue through the same piece or sub-outine of code...

So in short, if your proc doesnt alter DATA in memory, you "should" be safe with out the above considerations. However, if there is DATA Mem involveded, the you need to syncronize the execution of critical areas like the one discussesd above.


This will avoid the 'fatal crashes' from memory management issues..
Posted on 2002-03-09 01:25:37 by NaN
m00p and Nan,
Windows already provides a bunch of APIs for dealing with critical sections, check out the info here.
Posted on 2002-03-09 06:51:40 by sluggy
Whether or not two threads will crash when they both call a function at the same time depends on whether any shared resources are updated. In fact, any two functions (they can be the same function) on two threads can crash if shared resources aren't updated correctly.

Some (updatable) shared resources are open files, global memory, any memory shared via pointers, and open communication ports.
Posted on 2002-03-11 21:02:39 by tenkey
Sluggy,

Thanx for the tip, its good stuff to know about :grin:


NaN
Posted on 2002-03-12 13:51:24 by NaN