Dalvik VM & Java Memory Model (Concurrent programming on Android)

Question

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

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

<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