I bet your code doesn't actually look like that -- because why would you be
checking for it to be null, if it were? And you would have to declare the
'status' variable 'final', for thread class to be able to reference it.In
which case, you could not be assigning it like this. This is clearly not
like your actual code, in some important way. Maybe it's a field?
And the Thread.start() method doesn't return a value, so your code can't be
written like that.
Without your actual code, I can't analyze why it might be null. It could
happen long AFTER the code in question, because you don't know when the new
thread starts. If you ever set it to null LATER -- that could be your
culprit.
But -- ANY time you may be modifying a field in one thread, and looking at
it in another, you need to synchronize on some common object. Often, this
will be the object containing the field, but sometimes you may choose
something more fine-grained, including allocating a new Object() just to
synchronize on.
In its most basic form, assuming 'status' is a field in the outer class:
synchronized (this) {
status = new Status();
}
Thread thread = new Thread(){
public void run() {
synchronized (OuterClass.this) { // Gotta get the *right* this,or it's
all pointless!
if (status == null) {
throw new NullPointerException("Status was null"); // Surely
you want something more useful than just "NullPointerException" as your
message!
}
}
}
};
thread.start();
You should do this around every read and write of the field in question.
Locks are nice and all, but synchronized { } is more fundamental to the
language and threading in general, and you should learn to use and
understand it.
Locks are more useful for handling access to larger collections of resources
and more complex scenarios. But for simply coordinating read/write access
to be sure you have a consistent view of the world between two threads,
synchronized {} is all you need.
(Technically, there are exceptions to my stated rule, but there's no reason
to complicate your life thinking about them. Just always synchronized any
shared state between threads as a matter of policy, and you'll be fine on
that score).
One thing to be aware of, when using any type of locking, is the potential
for deadlocks.
Thread 1:
Lock A
Lock B
Thread 2:
Lock B
Lock A
In this scenario, you can have Thread 1 with A locked, and needing B, and
Thread 2 having B locked, and needing A. This is called a deadlock.
To avoid it, have everybody lock things in the same order. You don't have to
think about this if you're just locking a single object (as in our case
above). But if you need to lock two objects (for example, to copy data
between them) you need to be aware of the issue.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
