Sincronizacion de procesos_android

1,105 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,105
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
27
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Sincronizacion de procesos_android

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

×