Each thread will have it's own stack and set of registers. The other
components are down to how you write your code. A penalty occurs when a
thread context switches but that is a different story.
If you create two threads with instances of class X then they each will own
totally separate instances of X. All calls will operate as in a single
threaded application provided that they are not sharing resources! The code
of X may be shared but the data will be totally separate.
If X has a constructor that takes an object Y and for each of the classes
above you provide the same Y object then this becomes a shared resource
(shared resources can be databases, files, handles, registry anything where
a potential collision could occur (i.e. two threads trying to write to the
same stream isn't a good idea)).
Say that Y is a counter for the number of times something happens (an
instance of where you would want a single instance shared). In this scenario
Y is a shared object and just doing count++ is a property or method is not
going to cut it.
You get nasty things like race conditions where both threads try and update
the count at exactly the same time. It may not happen very often but you can
lose data, get random crashes and unpredictable behaviour.
What we need to do is either make Y thread safe or serialise access to the
shared components.
In our example in class Y with the counter property we can either:
1. lock the object. This is a Monitor or Critical section and will prevent
any other threads in whilst a thread owns it. If another thread comes along
while a thread is owning the lock then it will block (wait until it becomes
free) otherwise it will claim the lock and execute the code (hence only one
thread can be executing the code within the lock statement).
public void IncrementCounte r()
{
lock(y) { this.counter++; }
}
2. The Interlocked class provides some atomic functions for manipulating
simple scalar types (Int32, Int64) etc. The operations take exactly one
clock tick so there is no chance of two threads getting part way through an
operation (i.e. as in load value, increment, store value; it's just
increment value).
public void IncrementCounte r()
{
Interlocked.Inc rement(this.cou nter);
}
There are also lots of classes to control synchronisation (Monitor, Events,
Semaphore, Mutexes) but hopefully the above will get you started.
With different shared resources you get different problems. In memory
objects are fairly easy to serialise but SQL database access need careful
consideration as the database is also obviously multi-user so you shouldn't
need to serialise your code to access it, but depending on what calls you
make you can get into deadlock situations where two threads (or even
different processes on different computers) are going after the same locks
on a shared resource (being a SQL database table).
HTH
- Andy
"Extremest" <dn**********@c harter.netwrote in message
news:11******** **************@ i3g2000cwc.goog legroups.com...
>I am new to threading and trying to figure some things out. Are all
variables in a thread set to only that thread? Meaning if I create 2
instances of a class and then put each one in a different thread and
run them will the local variables in functions be shared or will they
be thread safe?
