> Hello, Can someone please confirm the following and maybe provide some
> insight to make my concepts thorough. If there are no instance
> variables and only local variables, one does not need to worry about
> different threads accessing the same variable, right? If only local
> variables are being used in all classes, does one need to worry about
> synchronization/thread issues? When does one need to use the
> SingleThread Model ? Thanks for any information. J
I assume you mean local variables as in, "defined in the function", right?
If that's true, then, no, you needn't worry about contention, since each
thread has its own stack, and locals are allocated on the stack.
You would be best served getting a book on threading. Not necessarily
Java threads, but a book on threading concepts without a set language or
thread API. I would recommend SunSoft's Threads Primer.
The jist is this: each thread shares the same address space, but -not-
stack space (where local variables, the return address, yadda yadda yadda
is stgored). This means that each thread's thread of execution is
independent from the other threads. That's good. The shared address
space is also good, since it means that there is only one copy of the text
of your program in memory, yet the program can be running concurrently in
different threads.
The problem is that, anything that isn't on the stack, is in the address
space. That includes both instance and class variables. Thus, two
functions, in two *different threads*, can try and access the same spot in
the address space *at the same time* and yeild all sorts of wacky and
hard-to-spot bugs.
So imagine this:
foo() { j++; System.out.println(j); }
bar() { j--; System.out.println(j); }
where j is an instance or class variable.
If you had two threads executing foo and bar at the same time, and j
started with 3, you could get any of { (4, 3), (3, 3), (2, 3) } (where
that is the output from foo and the output from bar). To see why, think
what would happen if the system swapped threads halfway through the
function calls. It could look like:
j++;
j--;
print;
print;
and you'd get 3, 3. etc.
In many cases, synchronization is a waste of time. If you had a page
counter servlet, who cares if it's off by a few? But other things, like
manipulating shared data structures in memory, demand locking. The usual
approach is to put a monitor or mutex (same thing) around the code that
modifies the shared data. Sort of like checking out a file from RCS
before editing it, then making changes, then checking it back in. While
one thread has the mutex (MUTual EXclusion), no other thread can get that
same mutex. This provides the synchronization lock that keeps the memory
accesses atomic and exclusive.
If you don't want to learn about synchronization, then you can cheat and
use SingleThreadModel. Instead of just one servlet instance with
mutltiple threads, you get multiple *instances* each with only one thread.
So your *instance* variables are safe. Your *class* variables are *NOT*.
Jim
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
