Este documento analiza cómo los procesos y subprocesos funcionan en aplicaciones Android. Explica que por defecto todos los componentes de una aplicación se ejecutan en el mismo proceso y subproceso, pero que es posible configurarlos para que se ejecuten en procesos separados. También describe la jerarquía de importancia de los procesos y cómo Android decide cuáles procesos eliminar para liberar memoria. Finalmente, explica la importancia de no bloquear el subproceso de interfaz de usuario y las diferentes formas de acceder a él desde subproces

1. 1
UNIVERSIDAD TECNICA PARTICULAR DE LOJA
La Universidad Católica de Loja
Escuela de Ciencias de la Computación
Titulación de Sistemas Informáticos y Computación
Sincronización de procesos con
Android
Integrantes: Freddy Vera
Carlos Ojeda
Francisco Vargas
Cristian Lluay
Docentes: Fernanda Maricela Soto Guerrero
Fecha: 16/04/2013
Periodo académico
Abril 2013 - Agosto 2013

2. 2
Sincronización de procesos con
Android
Procesos y subprocesos
Cuando un componente de aplicación se inicia y la aplicación no tiene ningún otro
componente en funcionamiento, el sistema Android inicia un nuevo proceso de Linux para
la aplicación con un solo hilo de ejecución. De forma predeterminada, todos los
componentes de la misma aplicación se ejecutan en el mismo proceso y subproceso
(llamado el "principal" hilo). Si un componente de aplicación se inicia y que ya existe un
proceso para dicha aplicación (porque otro componente de la aplicación existe), entonces el
componente se inicia dentro de ese proceso y usa el mismo hilo de ejecución. Sin embargo,
usted puede hacer arreglos para diferentes componentes de la aplicación se ejecute en
procesos separados, y se pueden crear subprocesos adicionales para cualquier proceso.
Este documento analiza cómo los procesos y subprocesos trabajar en una aplicación
Android.
Procesos
De forma predeterminada, todos los componentes de la misma aplicación se ejecutan en el
mismo proceso y la mayoría de las aplicaciones no deberían cambiar esta situación. Sin
embargo, si usted encuentra que usted necesita para controlar qué proceso pertenece un
determinado componente, puede hacerlo en el archivo de manifiesto.
La entrada de manifiesto para cada tipo de componente de
elemento <activity> , <service> , <receiver> y<proveedor> -apoya un androide: Proceso
de atributo que se puede especificar un proceso en el que dicho componente se debe
ejecutar. Puede configurar este atributo para que cada componente se ejecuta en su propio
proceso o para que algunos componentes comparten un proceso mientras que otros no lo
hacen. También puede configurar android: proceso para que los componentes de las
diferentes aplicaciones se ejecutan en el mismo proceso-siempre que las aplicaciones
comparten el mismo ID de usuario y Linux están firmados con los mismos certificados.
El <application> elemento también es compatible con un androide: Proceso de atributo,
para establecer un valor por defecto que se aplica a todos los componentes.

3. 3
Android podría decidir cerrar un proceso en algún momento, cuando queda poca memoria y
requeridos por otros procesos que están más directamente al servicio del
usuario. Componentes de aplicaciones que se ejecutan en el proceso que ha matado en
consecuencia destruido. Un proceso que se inicia de nuevo por esos componentes cuando
hay más trabajo que hacer para ellos.
Al decidir qué procesos de matar, el sistema Android pesa su importancia relativa para el
usuario. Por ejemplo, más fácilmente se cierra un proceso de alojamiento actividades que
ya no son visibles en la pantalla, en comparación con un proceso de alojamiento actividades
visibles. La decisión de terminar un proceso, por lo tanto, depende del estado de los
componentes que se ejecutan en ese proceso. Las reglas que se utilizan para decidir que
procesa la interrupción se discuten a continuación.
Procesos del ciclo de vida
El sistema Android trata de mantener un proceso de aplicación para el mayor tiempo
posible, pero con el tiempo necesario para eliminar los antiguos procesos para reclamar
memoria para los procesos nuevos o más importante. Para determinar qué procesos a seguir
y que matar, el sistema coloca cada proceso en una "jerarquía de importancia", basada en
los componentes que se ejecutan en el proceso y el estado de los componentes. Los
procesos con el menor importancia se eliminan primero, luego los que tienen la importancia
más baja siguiente, y así sucesivamente, según sea necesario para recuperar los recursos del
sistema.
Hay cinco niveles en la jerarquía de importancia. La siguiente lista presenta los diferentes
tipos de procesos en orden de importancia (el primer proceso es más importante y
es asesinado el pasado ):
Primer plano proceso
Un proceso que se requiere para que el usuario está haciendo actualmente. Un proceso se
considera en el primer plano, si cualquiera de las condiciones siguientes son verdaderas:
Alberga una actividad que el usuario está interactuando con (la Actividad 's onResume
() método ha sido llamado).
Alberga un servicio que está destinado a la actividad que el usuario está interactuando.
Alberga un servicio que se ejecuta "en primer plano", el servicio ha
llamado startForeground () .
Alberga un servicio que está ejecutando uno de sus devoluciones de llamada de ciclo de
vida (OnCreate () , OnStart () , o OnDestroy () ).

4. 4
Alberga una BroadcastReceiver que está ejecutando su OnReceive () método.
Generalmente, sólo unos pocos existen procesos en primer plano en cualquier momento
dado. Son muertos sólo como un último recurso, si la memoria no es tan bajo que no todos
pueden seguir ejecutándose.Generalmente, en ese punto, el dispositivo ha alcanzado un
estado de paginación de memoria, lo que eliminar algunos procesos en primer plano se
requiere para mantener la interfaz de usuario sensible.
Proceso Visible
Un proceso que no tiene ningún componentes de primer plano, pero todavía puede afectar
lo que el usuario ve en la pantalla. Un proceso se considera que es visible si cualquiera de
las condiciones siguientes son verdaderas:
Alberga una actividad que no está en el primer plano, pero sigue siendo visible para el
usuario (suonPause () método ha sido llamado). Esto podría ocurrir, por ejemplo, si la
actividad de primer plano inició un diálogo, que permite la actividad anterior para ser visto
detrás de él.
Alberga un servicio que está destinado a una visible (o primer plano) actividad.
Un proceso visible se considera muy importante y no morirá a menos que esto es necesario
para mantener todos los procesos en primer plano en ejecución.
Servicio de proceso
Un proceso que está en marcha un servicio que se ha iniciado con la StartService () método
y no están incluidos en ninguna de las dos categorías más altas. Aunque los procesos de
servicio no están directamente relacionados con todo lo que el usuario ve, por lo general
hacer las cosas que el usuario le interesan (como la reproducción de música en segundo
plano o transferencia de datos en la red), por lo que el sistema sigue en funcionamiento a
menos que no hay suficiente memoria para retenerlos junto con todos los procesos de
primer plano y visibles.
Antecedentes proceso
Un proceso que mantiene una actividad que no es actualmente visible para el usuario (de la
actividad OnStop () método ha sido llamado). Estos procesos no tienen un impacto directo
en la experiencia del usuario, y el sistema puede matar en cualquier momento para
recuperar la memoria para un primer plano, visible, o proceso de servicio. Por lo general,
hay muchos procesos fondo de funcionamiento, por lo que se mantienen en un LRU (menos
utilizado recientemente) lista para asegurarse de que el proceso con la actividad que fue
visto más recientemente por el usuario es el último en ser matado. Si una actividad práctica
sus métodos de ciclo de vida correctamente, y guarda su estado actual, matando a su

5. 5
proceso no tendrá un efecto visible sobre la experiencia del usuario, ya que cuando el
usuario se desplaza de nuevo a la actividad, la actividad restaura la totalidad de su estado
visible. Ver la Actividades documento para obtener información acerca de cómo guardar y
restaurar el estado.
Proceso de vacío
Un proceso que no se cumple ninguno de los componentes de aplicaciones activas. La
única razón para mantener este tipo de proceso vivo es con fines de almacenamiento en
caché para mejorar el tiempo de arranque la próxima vez que un componente necesita para
funcionar en él. El sistema a menudo mata a estos procesos con el fin de equilibrar los
recursos generales del sistema entre cachés de proceso y los cachés del núcleo subyacente.
Android clasifica en un proceso en el nivel más alto que puede, basándose en la
importancia de los componentes activos actualmente en el proceso. Por ejemplo, si un
proceso aloja un servicio y una actividad visible, el proceso se clasifica como un proceso no
visible, un proceso de servicio.
Además, la clasificación de un proceso podría aumentar debido a otros procesos dependen
de ella, un proceso que está sirviendo a otro proceso no puede ser clasificado bajo que el
proceso se está cumpliendo. Por ejemplo, si un proveedor de contenidos en el
procedimiento A está sirviendo a un cliente en el proceso B, o si un servicio en el
procedimiento A se enlaza a un componente en el proceso B, el proceso A se considera
siempre al menos tan importante como el proceso B.
Debido a que un proceso que se ejecuta un servicio ocupa el puesto más alto que un
proceso con actividades en segundo plano, una actividad que se inicia una operación de
larga duración harían bien en empezar un servicio de esa operación, en lugar de
simplemente crear un subproceso de trabajo, sobre todo si la operación es probable que
sobrevivir a la actividad. Por ejemplo, una actividad que ha de cargar una imagen a un sitio
web debe iniciar un servicio para realizar la carga de manera que la carga puede continuar
en el fondo, incluso si el usuario abandona la actividad. El uso de un servicio garantiza que
la operación tendrá por lo menos "proceso de servicio" prioridad, independientemente de lo
que suceda con la actividad. Esta es la misma razón que los receptores de radiodifusión
deben emplear los servicios en lugar de simplemente poner mucho tiempo en las
operaciones de un hilo.

6. 6
Hilos
Cuando se inicia una aplicación, el sistema crea un hilo de ejecución para la aplicación,
llamada "main". Este hilo es muy importante, ya que es el encargado de enviar los eventos
a los elementos de interfaz de usuario apropiados, incluidos los eventos de dibujo. También
es el hilo en el que la aplicación interactúa con los componentes del kit de herramientas de
interfaz de usuario Android (componentes de la android.widget y
android.view paquetes). Como tal, el hilo principal está también llamado a veces el hilo de
interfaz de usuario.
El sistema es no crear un subproceso independiente para cada instancia de un
componente. Todos los componentes que se ejecutan en el mismo proceso que se ejecute en
el hilo de interfaz de usuario y las llamadas al sistema para cada componente se envían de
ese hilo. Por consiguiente, los métodos que responden a las devoluciones de llamada de
sistema (tal como onKeyDown () para informar las acciones del usuario o un método de
devolución de llamada de ciclo de vida) siempre se ejecutan en el subproceso de interfaz de
usuario del proceso.
Por ejemplo, cuando el usuario toca un botón en la pantalla, los despachos de su aplicación
UI hilo del evento táctil para el widget, que a su vez establece su estado presionado y
publica una solicitud de invalidación de la cola de eventos. El hilo de interfaz de usuario
dequeues la solicitud y notifica al widget que debe dibujarse.
Cuando la aplicación realiza una intensa labor en respuesta a la interacción del usuario, este
modelo solo hilo puede producir malos resultados a menos que poner en práctica su
aplicación correctamente. En concreto, si todo lo que está sucediendo en el hilo de interfaz
de usuario, la realización de operaciones de largo como el acceso a la red o las consultas de
base de datos se bloqueará la interfaz de usuario completa. Cuando el hilo está bloqueado,
no hay eventos pueden ser enviados, incluyendo eventos de dibujo. Desde la perspectiva
del usuario, la aplicación parece bloquearse. Lo que es peor, si el subproceso de interfaz de
usuario está bloqueada por más de unos pocos segundos (unos 5 segundos en la actualidad),
el usuario se presenta con el infame " La aplicación no responde "(ANR) de
diálogo. Después, el usuario puede optar por salir de la aplicación y desinstalarlo si no
están contentos.
Además, la interfaz de usuario de Android conjunto de herramientas es no seguro para
subprocesos. Por lo tanto, no se debe manipular la interfaz de usuario desde un subproceso
de trabajo-que debe hacer todo tipo de manipulación a su interfaz de usuario de la interfaz
de usuario de hilo. Por lo tanto, hay más que dos reglas para modelar solo hilo de Android:

7. 7
No bloquee el subproceso de interfaz de usuario
No acceder a la interfaz de usuario de Android toolkit desde fuera del subproceso de la IU
Los subprocesos de trabajo
Debido al modelo de hilo se ha descrito anteriormente, es vital para la capacidad de
respuesta de la interfaz de usuario de la aplicación que no bloquea el subproceso de interfaz
de usuario. Si tiene operaciones a realizar que no son instantáneos, usted debe asegurarse de
que hacerlas en hilos separados ("fondo" o hilos "trabajadores").
Por ejemplo, a continuación se muestra un código para un oyente click que descarga una
imagen de un hilo separado y lo muestra en un ImageView :
public void onClick(View v) {
new Thread(new Runnable() {
public void run() {
Bitmap b = loadImageFromNetwork("http://example.com/image.png");
mImageView.setImageBitmap(b);
}
}).start();
}
Al principio, esto parece funcionar bien, ya que crea un nuevo hilo para manejar el
funcionamiento de la red. Sin embargo, se viola la regla segunda del modelo de subproceso
único: no acceda a la interfaz de usuario de Android desde fuera del conjunto de
herramientas de interfaz de usuario hilo -esta muestra se modifica el ImageView desde el
subproceso de trabajo en lugar del hilo de interfaz de usuario. Esto puede resultar en un
comportamiento no definido e inesperada, lo que puede ser difícil y requiere mucho tiempo
para rastrear.
Para solucionar este problema, Android ofrece varias formas de acceder al hilo de interfaz
de usuario de otros subprocesos. Aquí está una lista de los métodos que pueden ayudar:
Activity.runOnUiThread (Ejecutable)
View.post (Ejecutable)
View.postDelayed (Runnable, largo)
Por ejemplo, usted puede corregir el código anterior utilizando la View.post
(Ejecutable) método:

8. 8
public void onClick(View v) {
new Thread(new Runnable() {
public void run() {
final Bitmap bitmap = loadImageFromNetwork("http://example.com/image.png");
mImageView.post(new Runnable() {
public void run() {
mImageView.setImageBitmap(bitmap);
}
});
}
}).start();
}
Ahora bien, esta aplicación es segura para subprocesos: el funcionamiento de la red se
realiza a partir de un hilo separado, mientras que el ImageView es manipulado desde el
subproceso de interfaz de usuario.
Sin embargo, como la complejidad de la operación crece, este tipo de código puede ser
complicado y difícil de mantener. Para manejar las interacciones más complejas con un
subproceso de trabajo, es posible considerar el uso de un controlador en su subproceso de
trabajo, para procesar los mensajes enviados desde el subproceso de interfaz de
usuario. Quizás la mejor solución, sin embargo, es extender la AsyncTask clase, que
simplifica la ejecución de tareas subproceso de trabajo que necesitan interactuar con la
interfaz de usuario.
Usando AsyncTask
AsyncTask le permite realizar trabajo asincrónico de la interfaz de usuario. Realiza las
operaciones de bloqueo en un subproceso de trabajo y publica los resultados en el hilo de
interfaz de usuario, sin necesidad de manejar los hilos y / o cuidadores de ti mismo.
Para usarlo, debe subclase AsyncTask y aplicar el doInBackground () método de
devolución de llamada, que se ejecuta en un grupo de subprocesos de fondo. Para actualizar
la interfaz de usuario, se deben implementar OnPostExecute () , que proporciona el
resultado de doInBackground () y se ejecuta en el subproceso de interfaz de usuario, por lo
que con seguridad se puede actualizar la interfaz de usuario. A continuación, puede ejecutar
la tarea llamando a execute () de la interfaz de usuario de hilo.
Por ejemplo, se puede implementar el ejemplo anterior utilizando AsyncTask esta manera:

9. 9
El sistema llama a esto para realizar el trabajo en un subproceso de trabajo y
lo entrega * los parámetros dados a AsyncTask.execute () * /
protegido Bitmap doInBackground ( Cadena ... urls ) {
retorno loadImageFromNetwork ( urls [ 0 ]);
}
/ ** El sistema llama a esto para realizar el trabajo en el subproceso de la IU y entrega
* El resultado de doInBackground () * /
protegido vacío OnPostExecute ( Bitmap resultado ) {
mImageView . setImageBitmap ( resultado );
}
}
Ahora la interfaz de usuario es seguro y el código es más sencillo, ya que separa el trabajo
en la parte que se debe hacer en un subproceso de trabajo y la parte que se debe hacer en el
subproceso de interfaz de usuario.
Usted debe leer el AsyncTask referencia para un entendimiento completo sobre el uso de
esta clase, pero aquí está una descripción rápida de cómo funciona:
Se puede especificar el tipo de los parámetros, los valores de progreso, y el valor final de la
tarea, el uso de genéricos
El método doInBackground () se ejecuta automáticamente en un subproceso de trabajo
OnPreExecute () , OnPostExecute () , y onProgressUpdate () se invoca en todo el hilo de
interfaz de usuario
El valor devuelto por doInBackground () se envía a OnPostExecute ()
Usted puede llamar a publishProgress () en cualquier momento en doInBackground () para
ejecutaronProgressUpdate () en el hilo de interfaz de usuario
Puede cancelar la tarea en cualquier momento, desde cualquier subproceso
Precaución: Otro de los problemas que pueden surgir cuando se utiliza un subproceso de
trabajo se reinicia inesperados en su actividad debido a un cambio de configuración en
tiempo de ejecución (por ejemplo, cuando el usuario cambia la orientación de la pantalla),
que pueden destruir su subproceso de trabajo. Para ver cómo puede conservar su tarea

10. 10
durante uno de estos reinicios y cómo cancelar correctamente la tarea cuando la actividad
se destruye, ver el código fuente de la Estantes aplicación de ejemplo.
Métodos seguros para subprocesos
En algunas situaciones, los métodos que implementan podríamos llamar desde más de un
hilo, y por lo tanto debe ser escrito para ser thread-safe.
Esto es sobre todo cierto para los métodos que pueden ser llamados de forma remota, tales
como métodos en un servicio de la envolvente . Cuando una llamada en un método
implementado en un IBinder se origina en el mismo proceso en el que el IBinder se está
ejecutando, el método se ejecuta en el hilo del que llama. Sin embargo, cuando la llamada
se origina en otro proceso, el método se ejecuta en un hilo seleccionados de un grupo de
hilos que el sistema mantiene en el mismo proceso que el IBinder (no es ejecutado en el
hilo de interfaz de usuario del proceso). Por ejemplo, mientras que un servicio de onBind
() método será llamado desde el hilo de interfaz de usuario de proceso del servicio, los
métodos implementado en el objeto que onBind () devuelve (por ejemplo, una subclase que
implementa los métodos de RPC) sería llamado a partir de hilos en la piscina. Debido a que
un servicio puede tener más de un cliente, más de un hilo de la piscina puede engranar el
mismo IBinder método al mismo tiempo. IBinder métodos deben, por lo tanto, ser
implementadas para la ejecución de subprocesos.
De manera similar, un proveedor de contenidos puede recibir solicitudes de datos que se
originan en otros procesos. Aunque el ContentResolver y ContentProvider clases ocultar
los detalles de cómo la comunicación entre procesos se gestiona, ContentProvider métodos
que responden a las peticiones de los métodos- query () , insert () , delete () , update () ,
y getType () se llaman de un grupo de subprocesos en el proceso del proveedor de
contenido, no el hilo de interfaz de usuario para el proceso. Debido a que estos métodos
podrían ser llamadas desde cualquier número de hilos a la vez, ellos también deben
aplicarse para la ejecución de subprocesos.
Comunicación entre procesos
Android ofrece un mecanismo de comunicación entre procesos (IPC) mediante llamadas a
procedimiento remoto (RPC), en los que se llama un método de una actividad o
componente de otra aplicación, pero ejecutar de forma remota (en otro proceso), con
cualquier resultado devuelto de nuevo a la persona que llama. Esto implica descomponer
una llamada de método y de sus datos a un nivel del sistema operativo puede entender,
transmitiendo desde el proceso local y el espacio de direcciones para el proceso remoto y el
espacio de direcciones, a continuación, volver a montar y volver a representar la llamada

11. 11
allí. Los valores de retorno se transmiten luego en la dirección opuesta. Android
proporciona todo el código para realizar estas operaciones de IPC, para que pueda centrarse
en la definición e implementación de la interfaz de programación de RPC.
Para realizar el IPC, la aplicación debe unirse a un servicio, utilizando bindService () . Para
obtener más información, consulte el Servicios de guía para desarrolladores.
Sincronización de procesos
El sistema operativo Android es un sistema multi-usuario de Linux en el que cada
aplicación es un usuario diferente. Por defecto, el sistema asigna a cada solicitud un único
ID de usuario Linux (el ID es utilizado sólo por el sistema y no se conoce de la demanda).
El sistema configura los permisos de todos los archivos en una aplicación para que sólo el
ID de usuario asignado a dicha aplicación pueda acceder a ellos.
Cada proceso tiene su propia máquina virtual (VM), por lo que el código de una aplicación
se ejecuta en forma aislada de otras aplicaciones. Por defecto, todas las aplicaciones se
ejecuta en su propio proceso de Linux. Android inicia el proceso cuando cualquiera de los
componentes de la aplicación que se ejecuta, a continuación, se cierra el proceso cuando ya
no se necesita o cuando el sistema debe recuperar memoria para otras aplicaciones.
De esta manera, el sistema Android implementa el principio de privilegios mínimos. Es
decir, cada aplicación, por defecto, sólo tiene acceso a los componentes que necesita para
hacer su trabajo y nada más. Esto crea un entorno muy seguro, en el que una aplicación no
puede acceder a partes del sistema para el cual no se le da permiso.
Cuando existan procesos concurrentes se deben emplear módulos para garantizar lo
consistencia de los datos.
Sincronización de procesos en Android
(LINUX)
En un instante dado, sólo un proceso puede ejecutarse en modo kernel. Aunque es posible
que se apliquen interrupciones hardware y software a este proceso, Linux no provoca la
planificación (scheduler) si el proceso actual está activo en modo kernel. Un proceso que se
ejecuta en modo kernel puede provocar, sin embargo, un cambio del proceso actual
suspendiendo su ejecución (dormir). Esta suspensión voluntaria se debe generalmente a la
espera de un evento, tal como el fin de una entrada/salida o la terminación de un proceso
hijo. Linux proporciona varios mecanismos que permiten a los procesos sincronizarse en

12. 12
modo kernel (implementadas en el código del kernel = servicios internos): las “bottom-
halves”, los temporizadores (timers), las colas de tareas, las colas de espera y los semáforos
(control de acceso a un recurso).
Bottom-halves.
Las “Bottom-halves” (BHs) que constituyen la versión primitiva de las funciones utilizadas
para dejar para más adelante los aspectos menos urgentes de las rutinas de servicio de las
interrupciones.
En muchos manejadores de interrupción no en necesario ni conveniente, realizar todo el
trabajo de atención y procesado de la interrupción durante la propia atención de la
interrupción: (1) parte del trabajo se puede retrasar utilizando en mecanismo denominado
“bottom-half” (segunda parte). (2)
Temporizadores del Kernel (timers).
Linux gestiona una lista de timers con el objetivo de poder poner procesos en espera
durante un periodo de tiempo determinado. Estos timers se organizan en forma de una lista
circular doblemente enlazada. Los timers a desencadenar en un futuro próximo se colocan
al principio de la lista, mientras que los elementos a desencadenar en un futuro lejano se al
final de dicha lista. La estructura timer_list, se define en el archivo linux/timer.h según la
siguiente estructura
struct timer_list {
struct list_head list;
unsigned long expires;
unsigned long data;
void (*function) (unsigned long);
volatile int running;
};
·
La variable timer_head, definida en el archivo kernel/sched.c, contiene la dirección del
primer elemento (timer) de la lista. La fecha de expiración (expires) se expresa en número
de ciclos de reloj desde el arranque del sistema. La variable global jiffies es mantenida por
el kernel (su valor se incrementa en cada interrupción de reloj) y contiene siempre el
número de ciclos de reloj transcurridos desde el arranque. Además, el campo expires tiene
el valor de jiffies cuando el manejador function debe ser invocado con data pasado como
parámetro.
Colas de Tareas.
A partir de la versión de la versión 2.0 del kernel de Linux se crearon las colas de tareas
como una ampliación de BHs que permiten encolar tantas funciones como se quiera para
después ser procesadas una tras otra. Aunque se llaman colas de tareas, realmente son
“pilas de funciones”, ya que son realmente funciones que se ejecutan en orden LIFO. Uno
puede crear una cola de tareas utilizando la macro DECLARE_TASK_QUEUE() y encola
las tareas utilizando queue_task(), pudiendo ser procesada la cola de tareas por la función
run_task_queue(). En lugar de crear nuestra propia cola de tareas, se pueden utilizar las 4

13. 13
colas de tareas que en Linux, include/linux/tqueue.h, se definen de forma predefinida: (1)
tq_timer, se ejecuta tras cada tic de reloj. (2) tq_inmediate, se ejecuta siempre que se
evalúan las BH. Por tanto, se puede “sustituir una BH” por una función insertada en esta
cola de tareas. (3) tp_scheduler, se ejecuta desde el scheduler antes de modificar el estado
de una tarea. (4) tq_disk, utilizada por los drivers de dispositivos cada vez que el VFS
(Virtual File System) espera leer algún buffer.
Colas de Espera.
Una cola de espera es una lista enlazada y circular de descriptores de procesos que se
encolan a la espera de algún recurso o evento. Cada descriptor de proceso contiene la
dirección de un descriptor de proceso así como un puntero al siguiente elemento en la cola.
Es importante no confundir las colas de espera con las colas de tareas. Colas de Tareas
(task queues): (1) utilizadas para postponer la ejecución de una función concreta del kernel,
(2) utilizadas normalmente desde los manejadores de interrupciones. Colas de Espera (wait
queues): (1) utilizadas para suspender la ejecución de un proceso hasta que se produzca una
cierta condición, (2) utilizadas normalmente en el código de las llamadas al sistema.
Semáforos.
Los semáforos constituyen un mecanismo general de sincronización de procesos además de
ser una herramienta para la programación concurrente. Un semáforo no es realmente un
mecanismo de comunicación, sino más bien un mecanismo de sincronización de procesos
(permite a los procesos compartir recursos (secciones críticas) y sincronizarse). En
informática, y más particularmente en el caso de los sistemas operativos, un semáforo se
utiliza para controlar el acceso a un recurso. Con los semáforos se pueden construir
secciones críticas para proteger datos compartidos, o utilizarlos como mecanismos de
sincronización.

14. 14
BIBLIOGRAFÍA
Recursos web disponibles en las siguientes URLs:
http://docencia.ac.upc.edu/FIB/grau/SO/enunciados/Teoria/T2-Procesos.pdf
http://www.slideshare.net/jonbonachon/sincronizacin-de-procesos-11397014
http://blogs.utpl.edu.ec/sistemasoperativos/2009/04/21/sincronizacion-de-procesos-3/
http://linux.linti.unlp.edu.ar/images/0/07/Concurrencia-sincronizacion-linux.pdf
http://techerald.com/page/android-proceso-de-sincronizacion.html
http://prezi.com/bxdp5ygrfuo6/android/?utm_source=website&utm_medium=prezi_land
ing_related_solr&utm_campaign=prezi_landing_related_author.