Модель памяти Dalvik VM и Java (одновременное программирование на Android)

Я работаю над проектами Android, которые связаны с множеством параллельных программ, и я собираюсь реализовать некоторые пользовательские материалы для взаимодействия между потоками (один из java.util.concurent не подходит для мои цели).

Параллельное программирование нелегко в целом, но с Dalvik кажется еще сложнее. Чтобы получить правильный код, вы должны знать некоторые конкретные вещи и что там, где проблема возникает с Dalvik. Я просто не могу найти подробную документацию о Dalvik VM. Большинство ресурсов Android (даже developer.android.com сосредоточено на API платформы и не предоставляет никакой глубокой информации о некоторых нетривиальных (или низкоуровневых) вещах).

Например, к какому редактору спецификации языка Java соответствует Dalvik VM? В зависимости от ответа обработка переменных volatile различна и влияет на любой параллельный код, который использует переменные volatile.

Уже есть некоторые смежные вопросы:

и некоторые ответы fadden очень полезны, но я все же хочу получить более подробное и полное понимание рассматриваемого вопроса.

Итак, под сырыми вопросами, которые мне интересны (я буду обновлять список при необходимости, когда придут ответы на предыдущие вопросы):

Где найти подробную информацию о Dalvik VM, которая может предоставить ответы на вопросы ниже?
К какому изданию спецификации языка Java Dalvik VM соответствует?
Если ответ на (2) является "третьим изданием", то насколько завершена поддержка Dalviks Java Memory Model в этой спецификации? И особенно, насколько полная поддержка семантики переменных volatile?
В Двойной проверке блокировки в Android fadden укажите следующий комментарий:

Угу. С добавлением ключевого слова "volatile" это будет работать на uniprocessor (все версии Android) и SMP (3.0 "сотовые" и более поздние версии)

Означает ли это, что Samsung Galaxy SII, у которого есть двухъядерный процессор, но только Android 2.3 может неправильно выполнить параллельный код? (конечно, Galaxy - всего лишь пример, вопрос о любом многоядерном устройстве с платформой до Android 3.0)
В Модель памяти Dalvik такая же, как Java? fadden предоставляет ответ следующим предложением:

В настоящее время версия Dalvik не соответствует действительности в отношении JSR-133

Означает ли это, что любой существующий правильный параллельный Java-код может работать некорректно на любой версии Android, выпущенной до даты публикации этого комментария?

Обновление # 1: ответ на комментарий @gnat (слишком длинный для комментария)

@gnat оставить комментарий:

@Alexey Dalvik не соответствует ни одному выпуску JLS, потому что для соответствия требуется передача JCK, которая не является вариантом для Dalvik. Означает ли это, что вы даже не можете применять стандартный Java-компилятор, поскольку он соответствует стандартной спецификации? это имеет значение? если да, то как?

Ну, мой вопрос был как-то неоднозначным. Я на самом деле имел в виду, что JLS - это не только правила реализации компиляторов Java, но и неявные рекомендации для любых реализаций JVM. Действительно, JLS, например, утверждает, что чтение и запись некоторых типов являются атомарными операциями. Это не очень интересно для компилятора, потому что чтение/запись переводится как раз в один код операции. Но для любой реализации JVM очень важно правильно реализовать эти коды операций. Теперь вы должны понять, о чем я говорю. Хотя Dalvik принимает и выполняет программы, скомпилированные со стандартным компилятором Java, нет никаких гарантий, что они выполняются правильно (как и ожидалось) только потому, что никто (кроме, может быть, Dalvik разработчики) знает, поддерживаются ли все функции JLS, используемые в программе, Dalvik.

Понятно, что JCK не является вариантом для Dalvik, и все в порядке, но программисты действительно должны знать, на каких функциях JLS они могут положиться, когда выполняют свой код на Dalvik. Но в документации нет никаких слов об этом. Хотя вы можете ожидать, что простейшие операторы типа =, +, -, * и т.д. Работают, как вы ожидаете, что о нетривиальных функциях, таких как семантика переменных volatile (что отличается во 2-м и 3-м выпусках JLS)? И последнее - это не самые нетривиальные вещи, которые вы можете найти в JLS и особенно в Java Memory Model.

Ответ 1

Я не полностью прочитал ваш вопрос, но в первую очередь не использовать волатильные, даже opengles кодеры не используют его для разных потоков ui vs renderer.

Использовать volatile тогда и только тогда, когда один поток пишет (скажем, для статического свойства некоторого класса) и другие чтения, даже тогда вам нужно синхронизировать, прочитайте это для некоторых хороших способов обработки отсчетов

Как синхронизировать статическую переменную среди потоков, работающих с разными экземплярами класса в java?

всегда использовать синхронизацию
не прыгайте в больших проектах для таких сложных тем, как параллельное программирование.
просмотрите образцы Android в играх, где они обсудили концепцию runnables, обработчиков и обмена сообщениями b/w threads (UI THREAD AND RENDERER THREAD).

Ответ 2

Я думаю, что вы ответили на свой вопрос, хотя вы не указали никаких подробностей относительно того, почему пакет java.util.concurrent не соответствует вашим потребностям, большинство мобильных приложений просто используют асинхронный ввод-вывод и минимум потоков. Эти устройства не являются суперкомпьютерами, способными к серьезной распределенной обработке, поэтому я немного затрудняюсь понять, почему java.util.concurrent не удовлетворяет ваши потребности.

Во-вторых, если у вас есть вопросы о реализации Dalvik и соответствует ли он JLS (это не так), казалось бы, причина в том, что единственной надежной поддержкой механизмов потоковой передачи будет то, что определяет язык - java.util. параллельное, runnable и локальное хранилище потоков.

Рука, переворачивающая что-либо за пределы встроенной языковой поддержки, только задает проблемы, и, как ваш вопрос предполагает, вероятно, не будет поддерживаться последовательным образом в Dalvik.

Как всегда, когда вы думаете, что можете делать потоки лучше, чем ребята, которые писали Java, подумайте еще раз.

Ответ 3

< скопировано из комментария > Dalvik не соответствует ни одному изданию JLS, потому что для соответствия требуется передача JCK, который не является вариантом для Dalvik. </скопировано из комментария >

программисты действительно должны знать, по каким функциям JLS они могут положиться, когда выполняют свой код на Dalvik

Я думаю, что единственный способ узнать их - изучить тестовый набор Dalvik (я уверен, что он один, и я ожидаю, что он открыт с открытым исходным кодом, не так ли?). Для любой функции, которая вам нужна, 1) попытайтесь найти тест, который потерпит неудачу, если ваша функция будет реализована неправильно и проверьте, достаточно ли тест. Если такого теста нет или он недостаточно хорош, 1a) добавить новый или улучшить существующий тест. Затем 2) выясните, успешно ли тест прошел против вашей целевой реализации. Если тест не был запущен, то 2a) запустите его самостоятельно и выясните, проходит ли он или не работает.

BTW выше примерно о том, как работает JCK. Основное различие заключается в том, что нужно потратить собственное время и усилия на Dalvik для вещей, которые вы получаете от Sun/Oracle как должное. Другое отличие, похоже, в том, что для Dalvik это не документировано, а Snorcle имеет четкие документы о том, что iirc

Но в документации нет никаких слов.

Хорошо, если на нем нет слов, я бы сказал, что качество документации Dalvik является субоптимальным. Мягко говоря

Ответ 4

Вот честный ответ. Если java.util.concurrent не соответствует задаче для вашей реализации, тогда ваша проблема не в java.util.concurrent, а в ваших первоначальных спецификациях дизайна. Пересмотрите свой дизайн, возможно, разместите здесь то, что в вашем дизайне делает использование простого мьютекса, а не задачи для вас, а затем сообщество может показать вам, как его лучше создать.