lunes, 14 de noviembre de 2011

2.12 CONCURRENCIA E INTERBLOQUEO (DEADLOCK)

Interbloqueo (dead bck)
 Es un programa de procesos ejecutándose  a un sistema (computador).  Un conjunto de recursos que son utilizados por dichos procesos.
 Se dice  que el conjunto de procesos se encuentra en un estado de  interbloqueo cuando todos los sus procesos se encuentran  esperando un recurso que mantiene  reteniendo otro proceso  de grupo.
Es un proceso esperando un evento que jamás se producirá (lo que produce uno que está esperando también). Dead bck
Concurrencia.
Comprende un gran número de cuestiones de diseño, incluyendo la la comunicación  entre procesos, comparación y comparecía por los recursos. Sincronización de la ejecución de varios procesos y asignación del tiempo de procesador a los procesos y es fundamental para que existan diseños  como multiprogramación, multiprocesos y proceso distribuido.
Los procesos son concurrentes si existen simultáneamente cuando dos o más procesos llegan al mismo tiempo a ejecutarse, se dice que  se  ha procesado una concurrencia de procesos.
Condiciones  para los interbloqueos  de recursos.
Condición de exclusión mutua: cada recurso se asigna en un momento dado a  solo un proceso o estar disponible.
Condición de condencion y espera: los procesos que actualmente  contiene recursos que se les otorgaran antes pueden solicitar nuevos recursos.
Condición no apropiativa: los recursos otorgados previamente  no se pueden quitar a un proceso por la fuerza deben  ser liberadas de manera explícita por el proceso que los  contiene.
Condición de espera circular: deben ser una cadena  circular de dos o más  procesos cada una  de los cuales espera un recurso contenido por el siguiente  miembro de la cadena.
                                      

2.11 PASOS DE MENSAJE

 El pasa de mensaje es una técnica  empleada en programación  concurrente para  aportar sincronización entre procesos  y permitir a la exclusión mutua  de manera similar a como se hace  con los semáforo, monitores, etc.
Su principal característica  es que no precisa  de manera  compartida, por  lo que es muy importante  en la programación  para sistemas distribuidos. Los elementos principales  que intervienen en el paso de mensajes es el proceso que envía, el que recibe  y el mansaje.
 Sistemas embebidos:
 Un sistema embebido o emporrado  es un sistema de computación diseñado para realizar una o algunas pocas funciones dedicadas frecuentemente a un sistema de computación  en tiempo real. Los sistemas embebidos se utilizan para usos muy diferentes a los usos generales  a los que suelen someterse  a las computadoras personales.
Por lo general los sistemas embebidos  la mayoría de los componentes  se encuentran incluidos en la placa base (la tarjeta de video, audio, modem etc.) aunque muchas veces los dispositivos no  lucen como computadoras, ejemplo relojes de taxi, registradoras, controles de acceso. Entre otras múltiples aplicaciones.
 Los componentes del monitor  son:
Inicialización. Contienen código a ser ejecutado cuando el   monitor es creado.
Datos privados.  Contiene  los procedimientos    privados  que solo pueden ser usados desde adentro del monitor  y no son visibles desde afuera.
Procedimiento del monitor.  Son los procedimientos que pueden a ser llamado  desde  fuera del monitor.
Caja de entrada.  Contiene a los hilos  que han llamado algún procedimiento  del monitor pero no han podido  adquirir permiso  para ejecutarlos  aun.
                                                   
                                                          Ventajas de monitores
1)      El control de los recursos  esta centralizado en el  monitor,  lo que hace más fácil  su mantenimiento. A diferencia de los  semáforos  que se  usa  código distribuidos en varias partes del programa.
2)      Prevé una mayor protección a las variables de control.

Desventajas de los monitores
1)      Los monitores tiene exclusividad de uso, es decir  la concurrencia está limitada  si muchos procesos  hacen uso del mis monitor.
2)      El uso de los monitores  es bastante costoso. Por qué se pierde eficiencia y  por tanto ay bloqueo de los procesos.

2.10 Monitores

Son objetos destinados a ser usados  sin peligro por más de  un hilo  de  ejecución.  La característica principalmente los define  en que sus métodos son  ejecutados  con exclusión mutua lo que  significa, que encada  momento  en el tiempo, un hilo como máximo puede estar  ejecutado  cualquiera de sus  métodos.  Esta exclusión mutua simplifica el racionamiento  de implementar monitores en lugar de código  a ser  ejecutado  en  paralelo.
El estado   y el estudió de los semáforos se puede ver en las llamadas a las funciones necesarias para utilizarlos que dan ser repetidas en el código del programa, haciendo fácil corregir errores y asegurar el buen funcionamiento de los algoritmos. Para evitar estos inconvenientes  desarrollando los monitores.
Monitores con señales
       Un monitor es un módulo de software que consta de uno o más procedimientos, una secuencia de inicialización y unos datos locales. Las características básicas de un monitor son las siguientes:
1.       Las variables de datos locales están sólo accesibles para los procedimientos del monitor y no para procedimientos externos.
2.       Un proceso entra en el monitor invocando a uno de sus procedimientos.
3.       Sólo un proceso puede estar ejecutando en el monitor en un instante dado; cualquier otro proceso que haya invocado al monitor quedará suspendido mientras espera que el monitor esté disponible.
       Solamente una llamada a un módulo monitor puede ser activada por vez. Esto protege a los datos dentro del monitor de accesos simultáneos de múltiples usuarios. Los usuarios que intentan acceder al monitor mientras este está ocupado son bloqueados en una cola de entrada al monitor.
       CWAIT(c): Suspende la ejecución del proceso llamado bajo la condición c. El monitor está ahora disponible para ser usado por otro proceso.
       CSIGNAL(c): Reanuda la ejecución de algún proceso suspendido después de un CWAIT() bajo la misma condición. Si hay varios procesos, elige uno de ellos; si no hay ninguno, no hace nada.

2.9. SEMÁFOROS

                     Funcionamiento de los semáforos

       Dos o más procesos pueden cooperar por medio de simples señales, de forma que se pueda obligar a detenerse a un proceso en una posición determinada hasta que reciba una señal específica. Cualquier requisito complicado de coordinación puede satisfacerse por medio de la estructura de señales adecuada. Para la señalización, se usan variables especiales llamadas semáforos. Para transmitir una señal por el semáforo, los procesos ejecutan la primitiva signal(s). Para recibir una señal del semáforo, los procesos ejecutan la primitiva wait(s); si la señal correspondiente aún no se ha transmitido, el proceso es suspendido hasta que tenga lugar la transmisión. Para lograr el efecto deseado, se pueden contemplar los semáforos como variables que tienen un valor entero sobre el que se definen las tres operaciones siguientes:  
            
1.       Un semáforo debe inicializarse con un valor no negativo.
2.       La operación wait decrementa el valor del semáforo. Si el valor del semáforo se hace negativo, el proceso que ejecuta el wait se bloquea.
3.       La operación signal incrementa el valor del semáforo. Si el valor no es positivo, se desbloquea a un proceso bloqueado por una posición wait.Las primitivas wait y signal se suponen atómicas, es decir, no pueden ser interrumpidas y cada rutina puede considerarse como un paso indivisible. Una versión más limitada es el semáforo binario, que sólo puede tomar los valores 0 y 1.

 En principio los semáforos binarios son más sencillos de implementar y tienen la misma potencia de expresión que los semáforos generales. Tanto en los semáforos como en los semáforos binarios se emplea una cola para mantener los procesos esperando en el semáforo. La política más equitativa mediante la cual se quitan los procesos de dicha cola es la FIFO. La única exigencia estricta es que un proceso no debe quedar retenido en la cola de un semáforo indefinidamente porque otros procesos tengan preferencia.
       Generalmente operadores como WAIT y SIGNAL operan en los semáforos de la siguiente manera. Cuando un proceso ejecuta un operador WAIT que tiene un valor de semáforo en 0, ese proceso se bloquea; si el valor es mayor que cero, el valor del semáforo es disminuido en 1 y el proceso continua. Cuando un proceso ejecuta un operador SIGNAL y hay procesos bloqueados (WAITING), uno de estos procesos es activado (puesto en la cola de listos). Si no hay procesos esperando el valor del semáforo se incrementa en 1. Se asume que procesos bloqueados por semáforos pierden el procesador y entran en una cola de espera (WAITING QUEUE) en vez de producir BUSY WAITING. También se asume que la cola de espera es FIFO.

2.8. EXCLUSIÓN MUTUA: SOLUCIONES PORN HADRWARE Y SOFTWARE.

ALGORITMOS DE SINCRONIZACIÓN CON ESPERA ACTIVA (BUSY WAITING)
Solución simple
       Se utiliza una variable global que indica el estado de la región crítica, la cual es consultada cuando se requiere entrar. Esta solución no funciona si se produce una interrupción inmediatamente antes de que la variable antes mencionada se active. (Similar al Segundo Intento de Dekker)

Algoritmo de Dekker
Primer intento
       Utilizaremos para su descripción el “protocolo del iglú”. Un proceso (P0 o P1) que desee ejecutar su sección crítica entra primero en el iglú y examina la pizarra. Si su número está escrito en ella, el proceso puede abandonar el iglú y continuar con su sección crítica. En caso contrario, abandona el iglú y se ve obligado a esperar, ingresando de vez en cuando para mirar la pizarra hasta que se le permita entrar a su sección crítica. Un proceso frustrado no puede hacer nada productivo hasta que obtiene permiso para entrar a su sección crítica (por ello, el nombre de espera activa), debiendo persistir y comprobar periódicamente el iglú, consumiendo tiempo del procesador mientras espera su oportunidad.
            Después de que un proceso haya obtenido acceso a su sección crítica y tras terminar con ella, debe volver al iglú y escribir el número del otro proceso en la pizarra.
Esta secuencia podría prolongarse indefinidamente y ningún proceso podría entrar en su sección crítica. Estrictamente hablando, esto no es un interbloqueo, porque cualquier cambio en la velocidad relativa de los dos procesos rompería este ciclo y permitiría a uno entrar en la sección crítica. Aunque no es probable que esta situación se mantenga por mucho tiempo, es una situación posible. Así entonces, se rechaza el cuarto intento.
Una solución correcta
            Hay que poder observar el estado de ambos procesos, que viene dado por la variable señal. Y de algún modo, se hace necesario imponer algún orden en la actividad de los dos procesos para evitar el problema de “cortesía mutua” que se observó en el cuarto intento. La variable turno del primer intento puede usarse en esta labor; en este caso, la variable indica qué proceso tiene prioridad para exigir la entrada a la sección crítica. Ahora hay un iglú “árbitro” con una pizarra llamada “turno”. Cuando P0 quiere entrar en su sección crítica, pone su señal a cierto. A continuación, va y mira la señal de P1. Si ésta está puesta a falso, P0 puede entrar inmediatamente en su sección crítica. En otro caso, P0 va a consultar al árbitro. Si encuentra turno = 0, sabe que es momento de insistir y comprueba periódicamente el iglú de P1. Este otro se percatará en algún momento de que es momento de ceder y escribirá “falso” en su pizarra, permitiendo continuar a P0. Después de que P0 haya ejecutado su sección crítica, pone su señal a “falso” para liberar la sección crítica y pone turno = 1 para traspasar el derecho de insistir a P1.
          PROCESO 0     PROCESO 1    
       begin                                          begin
            repeat                                         repeat
                 señal_a = True;                           señal_b = True;
                 while (señal_b) do                        while (señal_a) do
                     if (turno) then                               if (!turno) then
                          begin                                          begin
                          señal_a = Falso;                         señal_b = Falso;
                          while (turno) do (nada);                         while (!turno) do (nada);
                          señal_a = True;                           señal_b = True;
                          end;                                           end; 
                 < sección crítica >;                      < sección crítica >
                 turno = 1;                                    turno = 0;
                 señal_a = Falso;                          señal_b = Falso;
                 < resto >;                                    < resto >;
            forever;                                            forever;
       end;                                            end;

Algoritmo de Peterson
       El algoritmo de Dekker resuelve el problema de la exclusión mutua, pero con un programa complejo. Entonces, Peterson desarrolló una solución más simple: la variable global señal indica la posición de cada proceso con respecto a la exclusión mutua y la variable global turno resuelve los conflictos de simultaneidad. Este algoritmo puede generalizarse para el caso de n procesos.
PROCESO 0                                               PROCESO 1          
begin                                                           begin
       repeat                                                  repeat
            señal_a = True;                                      señal_b = True;
            turno = 1;                                              turno = 0;
            while (señal_b and turno) do (nada);   while (señal_a and !turno) do (nada);
            < sección crítica >;                      < sección crítica >;
            señal_a = Falso;                          señal_b = Falso;
            < resto >;                                    < resto >;
       forever;                                                 forever;
end;                                                       end;




2.7. Principios Generales de concurrencia.

Es aparente que las nociones de procesos y recursos están estrechamente vinculadas. Un proceso es una tarea, identificada como una secuencia de instrucciones ejecutándose, o una colección de instrucciones formando un programa. Un recurso, por otra parte, es un término incluido en el sistema operativo, como también impresoras, discos, cintas de discos, procesos y repartos de la capacidad de memoria. Sin embargo, los recursos no son tratados en forma igualitaria por el S.O. y dependiendo de su cinta, tratará los procesos en forma diferente.
       Los recursos no expropiables (No Preemption) son usados por los procesos que requieren una utilización de recursos ininterrumpidos. Los recursos expropiables (Preemption) requieren un control del S.O. para cambiar correctamente la utilización de los recursos.
       En un sistema multiprogramado (se llama multiprogramación a la gestión de varios procesos dentro de un sistema monoprocesador), los procesos se intercalan en el tiempo para dar la apariencia de ejecución simultánea, aunque no se consigue un proceso paralelo real y aunque se produce una cierta sobrecarga en los intercambios de procesos de un sitio a otro, la ejecución intercalada produce beneficios importantes en la eficiencia del procesamiento y en la estructuración de los programas.
       En un sistema con varios procesadores, no sólo es posible intercalar los procesos, sino también superponerlos. Ambas técnicas, la intercalación y la superposición, pueden contemplarse como ejemplos de proceso concurrente y ambas plantean los mismos problemas. En el caso de un sistema monoprocesador, los problemas creados por la multiprogramación parten del hecho de que la velocidad relativa de ejecución de los procesos no puede predecirse. Depende de la actividad de otros procesos, de la forma en que el sistema operativo trata las interrupciones y de las políticas de planificación.
       La concurrencia comprende un gran número de cuestiones de diseño, incluyendo la comunicación entre procesos, compartición y competencia por los recursos, sincronización de la ejecución de varios procesos y asignación del tiempo de procesador a los procesos.







Labores del Sistema Operativo
       Hay algunos elementos de gestión y diseño que surgen por causa de la concurrencia. Se pueden enumerar los siguientes:
-          El S.O. debe ser capaz de seguir la pista de los distintos procesos activos. Esto lo hace por medio de los PCB.
-          El S.O. debe asignar y quitar los distintos recursos a cada proceso activo.
-          El S.O. debe proteger los datos y los recursos físicos de cada proceso contra injerencias no intencionadas de otros procesos
-          Los resultados de un proceso deben ser independientes de la velocidad relativa a la que se realiza la ejecución con respecto a otros procesos concurrentes.

Condiciones de concurrencia (Berstein)
       Debe darse un conjunto de condiciones para que se puedan ejecutar varios procesos a la vez.
       Un conjunto de lectura R(Si) de la sentencia Si es aquel formado por todas las variable que son referenciadas por la sentencia Si durante su ejecución sin sufrir cambios.
       Un conjunto de escritura W (Si) de la sentencia Si es aquel formado por todas las variable cuyos valores son modificados durante su ejecución.
       Dos sentencias Si y Sj pueden ejecutarse concurrentemente (produciendo igual resultado que la ejecución secuencial) si y solo si cumplen las siguientes condiciones:
R (Si) Ç W (Sj) = Æ
R (Sj) Ç W (Si) = Æ    
W (Si) Ç W (Sj) = Æ   

       Existen diversas notaciones para especificar actividades concurrentes. Entre ellas, las instrucciones fork-join (no estructurados) y cobegin-coend (estructurados).
       Un proceso es independiente si no puede afectar o ser afectado por otros procesos corriendo en el sistema. Un proceso es interactuante si puede afectar o ser afectado por otros procesos.
       Los procesos que se ejecutan, no lo hacen a la misma velocidad. Por ello, aparece una race condition (condición de carrera o de concurso), que es la situación en la cual el resultado de la ejecución de dos o más procesos interactuantes depende del orden de ejecución de los mismos.
INTERACCIÓN ENTRE PROCESOS

       Es posible clasificar las interacciones entre procesos en función del nivel de conocimiento que cada proceso tiene de la existencia de los demás. Existen tres niveles de conocimientos:
§         Los procesos no tienen conocimiento de los demás: estos son procesos independientes que no están pensados para operar juntos. El S.O. tiene que encargarse de la competencia por los recursos. Los resultados de un proceso son independientes de las acciones de los otros procesos.
§         Los procesos tienen un conocimiento indirecto de los otros: los procesos no conocen a los otros por su nombre, pero comparte el acceso a algunos objetos, tales como un buffer de E/S o un archivo o una porción de memoria. Estos procesos muestran cooperación para compartir el objeto común. Los resultados de un proceso pueden depender de la información obtenida de los otros. Este es el nivel de conocimiento menos frecuente, pero el más grave porque debemos tener la información actualizada. Podemos permitir lecturas simultáneas y para ello se hacen copias para que cada proceso lea de su propia copia. Las escrituras se hacen en una copia primaria y el S.O. debe actualizar todas las otras copias para mantener la actualización y coherencia de datos.
§         Los procesos tienen conocimiento directo de los otros: los procesos son capaces de comunicarse con los demás por el nombre y están diseñados para trabajar conjuntamente en alguna actividad. Estos procesos muestran cooperación por comunicación. Los resultados de un proceso pueden depender de la información obtenida de los otros.
Competencia entre los procesos por los recursos
       Los procesos concurrentes entran en conflicto cuando compiten por el uso del mismo recurso. Cada proceso debe dejar tal y como esté el estado de cualquier recurso que utilice. Aunque no hay intercambio de información entre los procesos en competencia, la ejecución de un proceso puede influir en el comportamiento de los procesos que compiten. En particular, si dos procesos desean acceder a un único recurso, el S.O. le asignará el recurso a uno de ellos y el otro tendrá que esperar. Por lo tanto, el proceso al que se le niega el acceso quedará bloqueado y se retrasará. En el peor caso, el proceso bloqueado puede que no consiga nunca acceder al recurso y, por tanto, no terminará con éxito nunca.








       En el caso que haya procesos en competencia, se deben solucionar tres problemas de control:

1.       Exclusión mutua: supóngase que dos procesos quieren acceder a un único recurso no compartible. A estos recursos se los llama recursos críticos y la parte del programa que los utiliza se conoce como sección crítica del programa. Es importante que sólo un programa pueda acceder a su sección crítica en un momento dado. Hacer que se cumpla la exclusión mutua crea los dos problemas mencionados a continuación.
2.       Interbloqueo (deadlock): considérese dos procesos P1 y P2 y dos recursos críticos R1 y R2. Supóngase que cada proceso necesita acceder a ambos recursos para llevar a cabo una parte de su función. En tal caso, es posible que el S.O. asigne R1 a P2 y R2 a P1. Cada proceso está esperando a uno de los dos recursos y ninguno liberará el recurso que ya posee hasta que adquiera el otro y ejecute su sección crítica. Ambos procesos están interbloqueados. En otra situación que se da interbloqueo es cuando dos procesos están bloqueados en un receive() y esperan un mensaje que nunca les va a llegar.
3.       Inanición (starvation): es cuando un proceso se queda esperando un recurso indefinidamente. Esto se soluciona asignándoles mayor prioridad a los procesos para que obtengan pronto el recurso que solicitan y no caigan en inanición (Envejecimiento o Aging).

Cooperación entre procesos por compartición

       Varios procesos pueden tener acceso a variables compartidas, archivos o bases de datos compartidas. Los procesos pueden emplear y actualizar los datos compartidos sin hacer referencia a los otros procesos, pero son conscientes de que estos otros pueden tener acceso a los mismos datos. Así pues, los procesos deben cooperar para asegurar que los datos que se comparten se gestionen correctamente. Los mecanismos de control deben garantizar la integridad de los datos. Puesto que los datos se guardan en recursos (dispositivos, memoria), también se presentan los problemas de control de exclusión mutua, interbloqueo e inanición. La única diferencia es que se puede acceder a los datos de dos formas distintas, para lectura y para escritura. Sólo las operaciones de escritura deben ser mutuamente excluyentes. Sin embargo, antes que estos problemas, se debe introducir un nuevo requisito: la coherencia de los datos. En este caso, la secuencia completa de cada proceso se puede declarar como sección crítica para garantizar la integridad de los datos, incluso aunque ningún recurso crítico se vea involucrado.







Cooperación entre procesos por comunicación
      
En los dos casos ya expuestos cada proceso posee su propio entorno aislado, que no incluye a los otros procesos; las interacciones entre los procesos son indirectas. Cuando los procesos cooperan por comunicación, en cambio, los distintos procesos participan en una labor común que une a todos los procesos. La comunicación es una manera de sincronizar o coordinar las distintas actividades. Normalmente, la comunicación puede caracterizarse por estar formada por mensajes de algún tipo. Las primitivas para enviar y recibir mensajes pueden venir dadas como parte del lenguaje de programación o por el núcleo del S.O.

Grado de Conocimiento
Relación
Posibles problemas de control
Los procesos no tienen conocimiento de los demás
Competencia
Exclusión mutua
Interbloqueo
Inanición
Los procesos tienen conocimiento indirecto de los otros
Cooperación por compartición
Exclusión mutua
Interbloqueo
Inanición
Coherencia de datos
Los procesos tienen conocimiento directo de los otros
Cooperación por comunicación
Interbloqueo
Inanición


Región Crítica. Protocolo de sincronización.
       Los puntos de entrada de un recurso indican la cantidad de procesos que pueden utilizar simultáneamente al mismo. Si un recurso tiene sólo un punto de entrada, se lo denomina recurso crítico o recurso no compartible.
       Región crítica de un proceso es la fase o etapa en la vida de ese proceso concurrente en la cual accede a un recurso crítico para modificarlo o alterarlo.
       El uso adecuado de la concurrencia entre procesos exige la capacidad de definir secciones críticas y hacer cumplir la exclusión mutua. Cualquier servicio o capacidad que dé soporte para la exclusión mutua debe cumplir con un protocolo de sincronización, que tiene los requisitos siguientes:
Debe cumplirse la exclusión mutua: sólo un proceso de entre todos los que poseen secciones críticas por el mismo recurso u objeto compartido, debe tener permiso para entrar en ella en un instante dado.
Un proceso que se interrumpe en una sección no crítica debe hacerlo sin estorbar a los otros. Es decir que si se cuelga un proceso que está usando un recurso, los demás procesos que esperan deben poder acceder al recurso de todas formas (el S.O. mata al proceso que se colgó y así libera al recurso). 
No se puede demorar indefinidamente la entrada de un proceso a un cierto recurso; no debe permitirse el interbloqueo y la inanición. Todos los procesos deben poder acceder al recurso que solicitan, sino se van a morir sin usarlo y no es justo.
Cuando ningún proceso está en su sección crítica, cualquier proceso que solicite entrar en la suya debe poder hacerlo sin dilatación. Es decir, si nadie está usando un cierto recurso, entonces se le otorga al primer proceso que lo solicite.
No se pueden hacer suposiciones sobre la velocidad relativa de los procesos o su número (cantidad de procesadores). Nunca se puede saber a priori si a un proceso le falta mucho o poco para terminar.
Un proceso permanece en su sección crítica sólo por un tiempo finito. Esto sirve para evitar que un proceso se quede con un recurso por mucho tiempo y para que un recurso no se quede trabado sin sentido.

2.6 Concurrencia: exclusión mutua y sincronización

Los temas fundamentales del diseño de sistemas operativos están relacionados con la gestión de procesos e hilos:
• Multiprogramación: consiste en la gestión de varios procesos dentro de un sistema mono-procesador.
• Multiprocesamiento: consiste en la gestión de varios procesos, dentro de un sistema multiprocesador.
• Procesamiento distribuido: consiste en la gestión de varios procesos, ejecutándose en sistemas de computadores múltiples y distribuidos. La reciente proliferación de las agrupaciones es el principal ejemplo de este tipo de sistemas.
La concurrencia es fundamental en todas estas áreas y para el diseño sistemas operativos. La concurrencia comprende un gran número de cuestiones de diseño, incluida la comunicación entre procesos, compartición y competencia por los recursos, sincronización de la ejecución de varios procesos y asignación del tiempo de procesador a los procesos. Se verá que estas cuestiones no solo surgen en entornos de multiprocesadores y proceso distribuido, sino incluso en sistemas multiprogramados con un solo procesador.
La concurrencia puede presentarse en tres contextos diferentes:
• Múltiples aplicaciones: la multiprogramación se creó para permitir que el tiempo de procesador de la máquina fuese compartido dinámicamente entre varias aplicaciones activas.
• Aplicaciones estructuradas: como ampliación de los principios del diseño modular y la programación estructurada, algunas aplicaciones pueden implementarse eficazmente como un conjunto de procesos concurrentes.
• Estructura del sistema operativo: las mismas ventajas de estructuración son aplicables a los programadores de sistemas y se ha comprobado que algunos sistemas operativos están implementados como un conjunto de procesos o hilos.
PRINCIPIOS GENERALES DE LA CONCURRENCIA
En un sistema multiprogramados con un único procesador, los procesos se intercalan en el tiempo aparentando una ejecución simultánea.
La intercalación y la superposición pueden contemplarse como ejemplos de procesamiento concurrente en un sistema monoprocesador, los problemas son consecuencia de la velocidad de ejecución de los procesos que no pueden predecirse y depende de las actividades de otros procesos, de la forma en que el sistema operativo trata las interrupciones surgen las siguientes dificultades:
Compartir recursos globales es riesgoso Para el sistema operativo es difícil gestionar la asignación óptima de recursos.
El hecho de compartir recursos ocasiona problemas, por esto es necesario proteger a dichos recursos.