source - Dalvik VM & Java Memory Model(Programación concurrente en Android)
project android source (4)
Aquí está la respuesta honesta. Si java.util.concurrent no está preparado para su implementación, entonces su problema no es java.util.concurrent sino sus especificaciones de diseño originales. Revise su diseño, tal vez publique aquí lo que en su diseño hace que usar mutex simples no sea una tarea fácil para usted y luego la comunidad puede mostrarle cómo diseñar mejor.
Estoy trabajando en proyectos de Android que involucran la mayoría de la programación concurrente y voy a implementar algunas cosas de comunicación entre subprocesos personalizados (el de java.util.concurent no es muy adecuado para mis propósitos)
La programación concurrente no es fácil en general, pero con Dalvik parece ser aún más difícil. Para obtener el código correcto, debe saber algunas cosas específicas y el problema con Dalvik. Simplemente no puedo encontrar una documentación detallada sobre la máquina virtual Dalvik. La mayoría de los recursos de Android (incluso developer.android.com se centró en la plataforma de la API y no proporciona ninguna información profunda sobre algunas cosas no triviales (o de bajo nivel)).
Por ejemplo, ¿a qué edición de la especificación de lenguaje Java se ajusta la máquina virtual de Dalvik? Dependiendo de la respuesta, el tratamiento de volatile variables volatile es diferente y afecta a cualquier código concurrente que use las variables volatile .
Ya hay algunas preguntas relacionadas:
- ¿El modelo de memoria de Dalvik es el mismo que el de Java?
- Doble comprobación de bloqueo en Android
y algunas respuestas de fadden son muy útiles, pero todavía quiero obtener una comprensión más detallada y completa de la materia en cuestión.
Así que debajo de una pregunta en bruto en la que estoy interesado (actualizaré la lista si es necesario, ya que llegarán las respuestas a las preguntas anteriores):
- ¿Dónde encontrar los detalles sobre la máquina virtual Dalvik que pueden proporcionar las respuestas a las preguntas a continuación?
- ¿A qué edición de la especificación del lenguaje Java se ajusta la máquina virtual de Dalvik?
- Si la respuesta a (2) es "tercera edición", ¿qué tan completo es el soporte de Dalviks al Modelo de Memoria Java desafiado en esta especificación? ¿Y especialmente cómo se completa el soporte para semánticas de variables
volatile? En el bloqueo controlado doble en Android, el fadden proporciona el siguiente comentario:
Sip. Con la adición de la palabra clave "volátil", esto funcionará en uniprocesador (todas las versiones de Android) y SMP (3.0 "panal" y posterior)
¿Significa que el Samsung Galaxy SII que tiene la CPU de doble núcleo pero solo Android 2.3 puede ejecutar el código concurrente incorrectamente? (Por supuesto, Galaxy es solo un ejemplo, la pregunta es acerca de cualquier dispositivo multinúcleo con plataforma pre-Android 3.0)
¿En el modelo de memoria de Dalvik es lo mismo que el de Java? Los fadden dan la respuesta con la siguiente frase:
Ninguna versión de Dalvik actualmente disponible es totalmente correcta con respecto a JSR-133
¿Significa que cualquier código de Java concurrente correcto existente puede funcionar incorrectamente en cualquier versión de Android publicada hasta la fecha de publicación de este comentario?
Actualización # 1: Respuesta al comentario de @gnat (demasiado largo para comentar también)
@gnat publica un comentario:
@Alexey Dalvik no se ajusta a ninguna edición de JLS, porque la conformidad requiere que se apruebe JCK, que no es una opción para Dalvik. ¿Significa que ni siquiera puede aplicar el compilador estándar de Java porque cumple con la especificación estándar? ¿eso importa? Si es así, ¿cómo?
Bueno, mi pregunta era de alguna manera ambigua. Lo que realmente quise decir es que JLS no es solo las reglas para las implementaciones del compilador de Java, sino también una guía implícita para cualquier implementación de JVM . De hecho, JLS , por ejemplo, afirma que la lectura y escritura de algunos tipos son operaciones atómicas . No es muy interesante para los compiladores porque la lectura / escritura se traduce solo en un solo código de operación. Pero es esencial para cualquier implementación de JVM que debería implementar estos códigos de operación correctamente. Ahora deberías ver de lo que estoy hablando. Si bien Dalvik acepta y ejecuta los programas compilados con el compilador estándar de Java, no existe ninguna garantía de que se ejecuten correctamente (como es de esperar) solo porque nadie (excepto tal vez los desarrolladores de Dalvik) sabe si todas las funciones de JLS utilizadas en el programa son compatibles con Dalvik.
Está claro que JCK no es una opción para Dalvik y está bien, pero los programadores realmente deberían saber en qué funciones de JLS pueden confiar cuando ejecutan su código en Dalvik. Pero no hay palabras sobre esto en la documentación. Si bien puede esperar que los operadores más simples como =, +, -, *, etc. funcionen como espera, ¿qué sucede con las características no triviales como la semántica de volatile variables volatile (que es diferente en las ediciones 2 y 3 de JLS )? Y esto último no es lo más no trivial que puede encontrar en JLS y en particular en el modelo de memoria de Java .
Creo que respondió a su propia pregunta, aunque no ha dado detalles sobre por qué el paquete java.util.concurrent no se ajusta a sus necesidades, la mayoría de las aplicaciones móviles simplemente usan IO asíncrona y un mínimo de subprocesos. Estos dispositivos no son procesadores distribuidos serios con capacidad para súper computadoras, por lo que me cuesta entender por qué java.util.concurrent no satisface sus necesidades.
En segundo lugar, si tiene preguntas sobre la implementación de Dalvik y si se ajusta a la JLS (no es así), parecería razonar que el único soporte confiable para los mecanismos de subprocesamiento serían aquellos que el lenguaje define - java.util.concurrent, ejecutable e hilo de almacenamiento local.
Hacer rodar todo lo que esté fuera del soporte de lenguaje incorporado es solo un problema, y como sugiere su pregunta, es probable que no sea compatible de manera consistente con Dalvik.
Como siempre, cuando crees que puedes hacer hilos mejor que los chicos que escribieron Java, piénsalo de nuevo.
No he leído tu pregunta por completo, pero en primer lugar no uses volátiles, incluso los codificadores opengles no lo usan para diferentes subprocesos ui vs renderer.
Use volatile si y solo si un hilo escribe (digamos a la propiedad estática de alguna clase) y otro lee, incluso si tiene que sincronizar, lea esto para conocer algunas buenas maneras de manejar los conteos.
- usar siempre sincronizar
- No salte a grandes proyectos para temas tan difíciles como la programación concurrente.
- revise las muestras de Android en los juegos en los que han discutido el concepto de runnables, manejadores e intercambio de mensajes en b / w hilos (UI HILO Y RENDER HILO).
<copiado del comentario> Dalvik no se ajusta a ninguna edición de JLS, porque la conformidad requiere pasar JCK que no es una opción para Dalvik. </ copiado del comentario>
los programadores realmente deberían saber en qué características de JLS pueden confiar cuando ejecutan su código en Dalvik
Creo que la única forma de que lo sepan es estudiar el conjunto de pruebas de Dalvik (apuesto a que hay uno y espero que sea de código abierto, ¿no?). Para cualquier función que necesite, 1) intente encontrar una prueba que falle si su función se implementa incorrectamente y verifique si la prueba se ve lo suficientemente bien. Si no hay tal prueba o no es lo suficientemente buena, 1a) agregue una nueva o mejore la prueba existente. Luego, 2) descubra si la prueba se ha ejecutado con éxito contra su implementación de destino. Si la prueba no se ha ejecutado, 2a) ejecútelo usted mismo y averigüe si pasa o no.
Por encima de BTW se trata aproximadamente de cómo funciona JCK . La principal diferencia es que uno tiene que invertir su propio tiempo y esfuerzo con Dalvik para las cosas que uno obtiene de Sun / Oracle por sentado. Otra diferencia parece ser que para Dalvik esto no está documentado, mientras que Snorcle tiene documentos claros en ese iirc
Pero no hay palabras sobre esto en la documentación.
Bueno, si no hay palabras sobre eso, diría que la calidad de la documentación de Dalvik no es óptima. Suavemente hablando