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