John T. Kerich wrote:
I have a global class that was created to hold the references to
different
classes and global variables. This global class is initialized by the
main
class (some variable are pass in as arguments) and all the other
threads do
a "gd = new Global()" to get their own copy of the class (this should be
done by the threads after initialization was done by main).
This is probably the immediate cause of your problems. Each
thread gets its own unique instance of Global to have and to hold.
If forty threads all do this, there will be forty distinct Global
objects floating around in the program. Make sure you understand
that, and then read on ...
The idea was
that since all the variables are saved in the class as "static" the other
threads would be able to access any variables saved in the global class
without parent class passing down a pointer to the global class
reference.
Here's the second point to ponder: No matter how many instances
of Global there are, there will be one and only one of each of the
Global class' static variables. If Global has `static short shrift;'
as a member, there will be exactly one Global.shrift even if there
are forty different Global instances. (There will be exactly one
Global.shrift even if there are *zero* Global instances, assuming
the Global class has been loaded at all.)
Note the discrepancy: Forty Global instances, but only one
Global.shrift. That's not necessarily a problem, but in this
case ... Keep reading.
I have found however that is design is not work correctly because one or
more threads are setting the same variables at that same time or
setting/getting a variable at the same time in the global class.
The original coder added while loop (see below) for the members that
he want
to be synchronized using a static locking flag, but in the debugger
(and in
real life) I can see both threads can see active as false and the
while loop
fails to stop one of the threads from executing the members code while
the
other is doing it!
static boolean active = false;
void synchronized connect() {
while (active) {
wait(50);
}
active = true;
member code
active = false;
}
(I'm assuming that both `active' and `connect' are in the
Global class.)
Question: How many different threads can execute connect()
simultaneously? Well, how many different Global objects are
there that a thread might choose to synchronize on? The first
thread synchronizes on its own Global object, acquires the object's
lock and plunges into connect(). Meanwhile, the second thread
synchronizes on its Global object, acquires that object's lock,
and also plunges into connect(). And the third, and fourth, and
although it might be something of an unlikely coincidence you'll
find that, yes, all forty threads could be executing connect()
simultaneously, each having locked its very own Global instance.
Question II: What have the forty threads done to stay out
of each other's way while mucking with the single Global.active
variable, the one that belongs to the whole Global class rather
than to any particular Global instance? They've done absolutely
nothing at all, that's what. So if all forty threads enter
connect() at the same time, many of them will execute the `while'
and see that active is false, and all of those will proceed
merrily to set it to true while they execute the `member code'.
On the evidence available, it seems the "original coder" you
mention did not understand synchronization. Instead of using one
traffic light to control access to a busy intersection, he's given
every car its own private light to consult.
To try and fix the problem I removed the while loop and adding
synchronization to one of the member declarations, but that didn't work
either!
By now, I hope you can see why.
I can see the main and one of the child threads calling the
initializing a socket connect member at the same time even after I
added the
synchronization to the function declaration.
Ah, `synchronized' was yours? Perhaps I begin to get a glimmer
of the original coder's motivation: He may have heard, somewhere,
that "synchronizing is slow" and tried to avoid it. And he wasn't
bright enough to realize that by doing so he created a problem that
not even the addition of `synchronized' can cure. (But read on ...)
I assume that synchronize will
only work for the same class reference and not between two copies on the
same class. I really don't want to recode the application and pass the
global class reference down to every thread/class that needs to call
global
so that synchronization will work, but it looks like that's what I am
going
to have to do to get synchronize to work.
It's not at all clear what you mean by "work." The `synchronized'
keyword "works" as designed, but I have a suspicion that you don't
understand the design.
Any ideas on how to fix this design problem without a major rewrite?
It's easy enough the fix the immediate problem. The thing you're
trying to control access to ("protect") with synchronization is the
collection of static variables belonging to the Global class. You
can only protect them if all threads agree not to touch them except
when synchronized on the very same object. It can be any object you
like, as long as all the threads can find it and synchronize on it;
for reasons of convenience and convention, a good candidate would be
the Class object for the Global class itself, Global.class.
How to synchronize on Global.class? You could do it explicitly:
void connect() {
synchronized(Global.class) {
method code
}
}
.... but there's an even more convenient way:
synchronized static void connect() {
method code
}
What's the difference between this and the original (aside from the
jettisoning of that silly `active' boolean and the useless cruft
that accompanied it)? In this version, connect() is a static method
rather than an instance method. So `synchronized' doesn't mean to
acquire the lock on `this' object -- there is no `this' for a static
method -- but to acquire the lock on the Class object. Bingo!
Problem solved.
... except that your grasp of synchronization seems so tenuous
at this point that I fear this may merely peel one layer off the
onion. For example: Have you noticed that the `new Global()' in
every thread is completely useless? If not, you haven't quite
understood things yet, and I foresee further difficulties. You
really, really need some education before trying to proceed; even
in Java, it takes discipline to write correct threaded code. You
are unlikely to get there just by trying things at random and hoping
for the best; even if you "get there," you won't have a reliable way
of knowing you've made it! The Java Tutorial has some material on
threading that may help, and any good textbook should explain it;
I strongly advise you to hit the books before coding yourself into
confusion. Good luck!