[android-developers] Re: How do I report a bug to htc?
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
[android-developers] Re: How do I report a bug to htc?
Also, if you ARE modifying the 'status' field later, expecting your other thread to have picked up its value, and maybe to have modified it or something, you're going to need to do some explicit synchronization, either using notify/wait, or some higher-level construction, for example a blocking queue. One common pattern would be to have a single blocking queue, shared between all interested threads. Threads that want something done (say, process a Status() object), push their work onto the queue. The thread that processes it loops, pulling stuff off the queue, and processing it. Since this is a blocking queue, it handles all the synchronization internally -- and will block the processing thread when there's no more work to be done. You can even have more than one processing thread. While it's quite possible to handle handoffs of data and control between threads using wait()/notify(), it's usually simpler to use a higher-level construct. There are certain exact patterns that work with wait/notify, and if you learn them, you can use them reliably, but blocking queues and similar approaches generally do what you want a lot more simply, and are easier to test. -- 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
[android-developers] Re: How do I report a bug to htc?
On Sep 27, 4:23 pm, sebastian_bugiu sebastian.bugiu.reloa...@gmail.com wrote: I have an application in android market that does not work on htc desire and I am positive the issue is not in my code. Basically I have a private static final field that is initialized to a reference to an object and yet whenever I access that object from another thread it throws a NullPointerException even though it is initialized. Are you sure you were really using private static final? Static finals are initialized when the class loads and will never change as long as that class remains loaded. All threads would be seeing the same value the entire time. The other code you showed can have a race condition in that first thread that assigns status may not have reconciled its local copy of the new Status object by the time the second thread tries to access it. You would need to synchronize both accesses or use volatile to keep them in sync. You are almost certainly not running into an HTC error. Doug -- 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
Re: [android-developers] Re: How do I report a bug to htc?
You need to use a Lock such as: http://developer.android.com/reference/java/util/concurrent/locks/ReentrantLock.html This sounds like a race conditions, as others have pointed out. These are usually the hardest to narrow down. Static variables are not a good idea in general unless you know exactly what you're doing. Try adding a lock around your static object, like: private static Object mMyProtectedVar; private final Lock mLock = new ReentrantLock(); Then before touching the variable, ALWAYS use the lock like so: mLock.lock(); mMyProtectedVar.something = something; mLock.unlock(); Java provides some keywords for making variables and methods thread safe, although I find a lock to be really clear as to its intended purpose. On Sat, Oct 1, 2011 at 6:42 PM, Doug beafd...@gmail.com wrote: On Sep 27, 4:23 pm, sebastian_bugiu sebastian.bugiu.reloa...@gmail.com wrote: I have an application in android market that does not work on htc desire and I am positive the issue is not in my code. Basically I have a private static final field that is initialized to a reference to an object and yet whenever I access that object from another thread it throws a NullPointerException even though it is initialized. Are you sure you were really using private static final? Static finals are initialized when the class loads and will never change as long as that class remains loaded. All threads would be seeing the same value the entire time. The other code you showed can have a race condition in that first thread that assigns status may not have reconciled its local copy of the new Status object by the time the second thread tries to access it. You would need to synchronize both accesses or use volatile to keep them in sync. You are almost certainly not running into an HTC error. Doug -- 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 -- ~ Jeremiah:9:23-24 Android 2D MMORPG: http://solrpg.com/, http://www.youtube.com/user/revoltingx -- 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
