I am working on Android projects which involve the lot of concurrent programming and I am going to implement some custom inter-threads communication stuff (the one from java.util.concurent are not well suited for my purposes).
The concurrent programming is not easy in general but with Dalvik it seems to be even harder. To get the correct code you should know some specific things and that where problem arise with Dalvik. I just can't find a detailed documentation about the Dalvik VM. Most Android resources (even the developer.android.com focused on platform API and doesn't provide any deep information about some non-trivial (or low-level) things).
For example, to which edition of Java Language Specification the Dalvik VM is conform ? Depending of answer the treatment of volatile
variables are different and affect the any concurrent code which use the volatile
variables.
There are already some related questions:
and some answers by fadden are very useful but I still want to get more detailed and complete understanding of matter in question.
So below a raw questions I am interesting in (I will update the list if necessary as answers for previous questions will arrive):
volatile
variables ?In the Double checked locking in Android the fadden provide the following comment:
Yup. With the addition of the "volatile" keyword, this will work on uniprocessor (all versions of Android) and SMP (3.0 "honeycomb" and later)
Does it mean that Samsung Galaxy SII which has the dual-core CPU but only Android 2.3 may execute the concurrent code incorrectly ? (of course Galaxy is only an example, the question is about of any multicore device with pre-Android 3.0 platform)
In the Is Dalvik's memory model the same as Java's? the fadden provide the answer with the following sentence:
No currently-shipping version of Dalvik is entirely correct with respect to JSR-133
Does it mean that any existing correct concurrent Java code may work incorrectly on any Android version released up to date of posting of this comment ?
@gnat post a comment:
@Alexey Dalvik does not conform to any JLS edition, because conformance requires passing JCK which is not an option for Dalvik. Does it mean that you even can't apply standard Java compiler because it conform to standard specification ? does that matter? if yes, how?
Well, my question was somehow ambiguous. What I actually meant is that JLS is not only the rules for Java compiler implementations but also an implicit guidelines for any JVM implementations. Indeed, JLS, for example, states that reading and writing of some types are atomic operations. It is not very interesting for compiler writer because read/write translated just into a single opcodes. But it is essential for any JVM implementation which should implement these opcodes properly. Now you should see what I am talking about. While Dalvik accept and execute the programs compiled with standard Java compiler there are no any guaranties that they are executed correctly (as you may expect) just because no one (except maybe Dalvik's developers) knows if all JLS's features used in the program are supported by Dalvik.
It is clear that JCK is not an option for Dalvik and it is Ok, but programmers really should know on which features of JLS they may rely when execute their code on Dalvik. But there is no any words about this in documentation. While you may expect that simplest operators like =, +, -, *, etc. are works as you expect what about non-trivial features like semantic of volatile
variables (which is different in 2nd and 3rd editions of JLS)? And latter is not the most non-trivial things you may find in JLS and particular in Java Memory Model.
The Dalvik Virtual Machine (DVM) is an android virtual machine optimized for mobile devices. It optimizes the virtual machine for memory, battery life and performance. Dalvik is a name of a town in Iceland. The Dalvik VM was written by Dan Bornstein.
Dalvik Virtual Machine provides high-performance features, better memory management, and battery life for low-powered handheld devices. It was developed exclusively for android devices and allowed several apps to execute on the virtual machine.
Android 4.4 "KitKat" brought a technology preview of ART, including it as an alternative runtime environment and keeping Dalvik as the default virtual machine. In the subsequent major Android release, Android 5.0 "Lollipop", Dalvik was entirely replaced by ART.
ART and its predecessor Dalvik were originally created specifically for the Android project. ART as the runtime executes the Dalvik Executable format and Dex bytecode specification. ART and Dalvik are compatible runtimes running Dex bytecode, so apps developed for Dalvik should work when running with ART.
I haven't read your question completely, but first of all do not use volatile, even opengles coders do not use it for different ui vs renderer threads.
Use volatile if and only if one thread writes (say to some class' static property) and other reads, even then you have to synchronize, read this for some good ways to handle counts
How to synchronize a static variable among threads running different instances of a class in java?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With