The known danger of multi-threading in android is accessing UI from another thread. But what other types of conflicts can occur in Android. Is it possible to have a deadlock using looper and handler? If so, how could this occur? Frankly I have not experienced deadlocks in Android, but I keep getting this question from folks, and don't really know how to answer it.
Bugs related to multithreading such as deadlocks and race conditions are no different on Android than other platforms. Giving you an exhaustive list of these problems and possible solutions is beyond the scope of this web site due to the necessary background you need to acquire.
The following URLs might answer your question:
http://www.techrepublic.com/article/avoid-these-java-threading-gotchas/
https://tudorturcu.wordpress.com/2013/05/15/some-multi-threading-gotchas/
Related
Are Android logging functions such as Log.d() and __android_log_print() safe to use in a multithreaded context? In particular, I'm wondering if it's guaranteed there will be no instability and that individual log messages won't be interleaved at the character level or otherwise jumbled.
It would seem this should be easy information to find, but for some reason I haven't been able to find anything conclusive. The documentation for Log and for the corresponding native functions doesn't seem to address the issue. In the documentation for Logger it's mentioned that all methods are thread safe, but it's the lower-level functions I'm wondering about specifically.
One would expect these functions to be thread safe, given that logging from multiple threads is probably common. Also, by default at least, in Android Studio each log message includes a thread identifier, and it would seem odd for the logger to be thread-aware but not thread safe.
I highly doubt there's anything to worry about here, but when it comes to multithreading it seems like a guarantee would be preferable, even when it seems obvious that the functionality in question must be thread safe.
Is this documented somewhere, and I've just missed it? If not, is it reasonable to assume that the functions in question are thread safe?
Android documentation, tutorials, videos and the like are filled with best practice on how to avoid non-essential processing on the UI thread. However, when creating a big app or using external components it can be hard to remember which methods block the UI thread and which do not. I've often seen threading mentioned in comments, but that seems error prone for lazy/rushed situations, and not everything gets an ideal code review.
What naming, annotation, or other conventions exist to help developers quickly determine if the methods they are considering are UI thread optimized or not?
I am developing an android application, and this application going to have lots of classes ( maybe 30 or more ). Will this slow down my application or is it a bad programming method?
I would be glad if someone can answer this.
Thanks :)
30 classes is definitely not considered "a lot". Most of the applications I develop for Android have about 100-200 classes.
This doesn't usually impact the application's runtime performance. If anything, it might slow down the compiling process, but this doesn't usually affect the decision making when writing code (no-one says "oh boy, the compile time is 5 seconds longer, better rethink my entire design").
Actually, spreading your code into multiple classes is usually the best way to go, if the division of code makes sense.
Things that will hurt the performance of your app usually involve wasteful loop iterations, deep recursions, etc.
My application is using 6 external libraries and apart from that I have 52 class files. Nothings seems to be creating any problem for me.
I have been discussing a problem on the Indy forums related to a thread that is not terminating correctly under Android. They have suggested that there may be an underlying problem with TThread for ARC.
Because this problem is holding up the release of a product a work around would be to simply forcibly terminate the thread. I know this is not nice but in this case I cant think of a side effect from doing so. Its wrong but its better than a deadlocked app.
Is there a way to forcibly terminate a thread under Android like TerminateThread does under windows?
Martin
Well, I don't think harshly terminating threads is advisable, but that notwithstanding, from what I read of the System unit, you should be able to use this:
uses Posix.Pthread;
...
pthread_detach(pthread_t(TheThreadObject.ThreadID));
Untested, mind.
The Andoid UI toolkit is not thread-safe, when you try to modify the UI from a worker thread you get the CalledFrowWrongThreadException (or something like that).
Moreover, the dev guide say:
[Manipulating the UI from a worker thread] can result in undefined and
unexpected behavior, which can be
difficult and time-consuming to track
down.
But it does not seem to me very difficult to understand what a CalledFrowWrongThreadException mean.
Does the documentation was written before the introduction of CalledFrowWrongThreadException or are there still cases where the exception is not thrown? (or where the error is indeed difficult and time-consuming to track down)
The main issue here is that checking what thread is calling a given function incurs a processing overhead; there are almost certainly calls that don't check for precisely this reason - it would slow down the UI rendering.
By extension, the reason UI functions aren't thread-safe is that if you through mutex code into the equation, the performance hit becomes even greater.
Just like Swing in Java, and WinForms in .NET, there may be cases where the method in question does not check to determine that you are calling from the proper thread, and therefore does not necessarily throw the expected exception.
Providing the above documentation is a way to cover themselves and explain a simple idea that actually requires a lot of effort to work around if you do not know it, or understand it, before the wrong thread exception is ever thrown by offending code, which may be much later down the road.