47

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):

  1. Where to find the details about the Dalvik VM which may provide the answers for questions below ?
  2. To which edition of Java Language Specification the Dalvik VM is conform to ?
  3. If answer to (2) is "third edition" then how complete the Dalviks's support of Java Memory Model defied in this specification ? And especially how complete the support for semantic of volatile variables ?

  4. 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)

  5. 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 ?

Update#1: Answer to @gnat's comment (too long to be comment too)

@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.

Community
  • 1
  • 1
Alexey Kryshen
  • 1,067
  • 2
  • 11
  • 15
  • 2
    StackOverflow is not an especially good resource for any of this stuff. You are asking platform implementation questions; StackOverflow tends to focus on the Android SDK. I recommend http://groups.google.com/group/android-platform for your sorts of questions. – CommonsWare Aug 07 '11 at 15:28
  • 1
    Note that fadden is the author of dalvikvm, so you can trust what he tells you. – Jesse Wilson Aug 07 '11 at 17:06
  • @CommonWare thanks for hint, I will try this group too – Alexey Kryshen Aug 07 '11 at 18:49
  • And I am actually very hope **fadden** may provide some additional comments (especially because I know he is work on Dalvik). – Alexey Kryshen Aug 07 '11 at 18:56
  • On one level, the source is avaible - but you shouldn't really depend on the implementation details you find there (as they may change) but only on what is in the developer docs perhaps extended by what the actual authors tell you when they post. – Chris Stratton Aug 07 '11 at 23:18
  • @Chris, the main problem that there is no documentation which answer of any of my question. Moreover, some docs within Android sources (not _public_ one) refer to Second edition of Java Language Specification while **fadden** states that JSR-133 is also applicable (and JSR-133 is actually is a part of Third edition). Does it mean that Dalvik is not conform to any edition but instead implement it own (actually speaking **closed**) specification ? Does it mean that you even can't apply standard Java compiler because it conform to standard specification ? A lot of questions but no answers! – Alexey Kryshen Aug 08 '11 at 09:42
  • 1
    @Alexey Dalvik does not conform to any JLS edition, because conformance requires passing [JCK](http://en.wikipedia.org/wiki/Technology_Compatibility_Kit#TCK_for_the_Java_platform) 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? – gnat Aug 16 '11 at 00:06
  • @gnat please see Update#1 in post, just too long to be a comment. – Alexey Kryshen Aug 16 '11 at 10:30
  • @Alexey thanks I'll transform my comment ot answer and will also add my perspective on the clarifying update – gnat Aug 16 '11 at 11:13
  • 2
    As of Honeycomb (3.0), Dalvik does provide all of the important JSR-133 guarantees. Dalvik is not Java, so there are no guarantees for the JLS in general, but it does have correct behavior for `volatile` and word-slicing of primitives. An overview of SMP issues on Android (focused on C++, Dalvik, and ARM) was recently made available at http://developer.android.com/training/articles/smp.html . – fadden Apr 17 '13 at 23:25
  • @fadden Please could you answer, why when I'm running Basic Example from here https://dzone.com/articles/java-volatile-keyword-0 on Android (Nexus 5 Android 6.0 / Lenovo i369 Android 4.4.2) I get correct results even if MY_INT is _not_ volatile? But when I run it (also MY_INT is _not_ volatile) on my laptop with 4 cores as ordinary .java file I get incorrect results, as it should be due to Java Memory Model. – Denisigo Oct 20 '16 at 15:32
  • Without `volatile`, you have a race condition, and the behavior is undefined. So you might see the changes on the other thread or you might not. – fadden Oct 20 '16 at 19:10
  • @fadden ok, so this is just a matter of circumstances, and there is no any special behavior for volatile in Android? I was just confused with that on my laptop there is explicit difference whether I'm using volatile or not, while on Android I observed the same correct behavior in both cases. – Denisigo Oct 21 '16 at 12:33
  • 1
    Volatile is implemented according to the JMM. The code you're running is too simple to show subtle differences. You can try the example from the Android SMP Primer appendix ( https://developer.android.com/training/articles/smp.html#smp_failure_example ); I've observed that failing without `volatile` on Android. I haven't tried it on recent devices though. – fadden Oct 21 '16 at 19:34

4 Answers4

2

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?

  1. always use synchronize
  2. do not jump at large projects for such difficult topics like concurrent programming
  3. go through android samples on games where they have discussed the concept of runnables, handlers, and exchanging messages b/w threads (UI THREAD AND RENDERER THREAD).
Community
  • 1
  • 1
Patt Mehta
  • 4,110
  • 1
  • 23
  • 47
1

I think you answered your own question, although you have given no details as to why the java.util.concurrent package does not fit your needs, most mobile apps simply use asynchronous IO and a minimum of threading. These devices aren't super computers capable serious distributed processing so I have a little difficulty understanding why java.util.concurrent wont meet your needs.

Secondly, if you have questions about the Dalvik implementation and whether it conforms to the JLS (it doesnt), it would seem to reason that the only reliable support for threading mechanisms would be those which the language defines - java.util.concurrent, runnable and thread local storage.

Hand rolling anything outside of the built in language support is only asking for trouble, and as your question suggests will likely not be supported in a consistent manner on Dalvik.

As always when you think you can do threading better than the guys who wrote Java, think again.

deleted_user
  • 3,817
  • 1
  • 18
  • 27
0

Here's the honest answer. If java.util.concurrent is not up to task for your implementation then your problem isn't java.util.concurrent but is instead your original design specifications. Revisit your design, maybe post here what in your design makes using simple mutex's not up to task for you and then the community can show you how to design it better.

Gimballon
  • 81
  • 7
0

<copied from comment> Dalvik does not conform to any JLS edition, because conformance requires passing JCK which is not an option for Dalvik. </copied from comment>

programmers really should know on which features of JLS they may rely when execute their code on Dalvik

I think the only way for them to know is to study Dalvik test suite (I bet there's one and I expect it is open source isn't it?). For any feature you need, 1) try to find a test that would fail if your feature is implemented incorrectly and check if the test looks good enough. If there's no such test or it's not good enough, 1a) add new or improve existing test. Then, 2) find out if the test has been successfully run against your target implementation. If test hasn't run then 2a) run it yourself and find out if it passes or fails.

BTW above is roughly about how JCK works. The main difference is that one has to invest own time and effort with Dalvik for things one gets from Sun/Oracle for granted. Another difference seems to be that for Dalvik this is not documented while Snorcle has clear docs on that iirc

But there is no any words about this in documentation.

well if there are no words on that then I'd say quality of Dalvik documentation is suboptimal. Softly speaking

gnat
  • 6,213
  • 108
  • 53
  • 73
  • 1
    _Dalvik documentation is suboptimal_. There is no public Dalvik's documentation at all and API docs is not good too: e.g. you may find a description of constructor with return value (nice ;)) but it is very rare to see a useful notes on pre- and post- conditions for the methods. As to tests you are proposed ... well, someone may try but note following: what if you want to use any existing Java code library? it also seems that different versions of Android has the different versions of Dalvik, and what you will do if they has no reasonable common set of supported _features_? – Alexey Kryshen Aug 16 '11 at 11:57
  • @Alexey well the popularity of Android platform makes me feel that concerns you raise are not really that important. By the way for all the _what-if_'s you mention I for one can think of at least one way to address these - and none is rocket science, one can figure it by a little thinking and applying common sense. Quoting self, _one has to invest own time and effort with Dalvik_ – gnat Aug 16 '11 at 12:58
  • _concerns you are raise are not really that important_. For users of Android's smartphones and tablets maybe. But I am personally not very happy with my Galaxy S and A500 due to the all these problems with browser (A500, hang ups), Android market (A500, is the application installation will success is 50/50), background worked Live Wallpapers (Galaxy S, just waste battery) and so on. Matter of quality. What I really want to know is asked in a initial post. Until I get answers I can't states that my code is quality (assumptions vs conformance), and as developer I am not happy with this. – Alexey Kryshen Aug 16 '11 at 13:51
  • _as developer_ I see. Well given the open source nature of Android I think you better be prepared to act as a tester yourself (including, but not limited to, acting as a conformance tester). If your prior background as a developer is Java (JCP, JLS, JCK, JDK, docs and specs) - forget it: all this boring, cumbersome (and sometimes exciting) testing stuff previously done by _Snorcle_ behind the scenes is now all yours – gnat Aug 16 '11 at 14:14
  • Since 3.0 Android is no longer open source AFAIK. – Alexey Kryshen Aug 16 '11 at 14:30
  • I see. That's interesting - thank you. Anyway, forget the stuff you had in Java: JCP, JLS, JCK, JDK, docs and specs. Or, more precisely, learn how this stuff is done at your target platform. Be prepared that it'll be much different from what you had in Java. Be prepared that there might be much more [DIY](http://en.wikipedia.org/wiki/Do_it_yourself) there than it was in Java. Once again, thing worth keeping in mind is that Android popularity rather strongly indicates that all this is not too difficult. – gnat Aug 16 '11 at 15:10