|
Por: 04-05-2009 por EstebanYomairo |
Categorías asociadas: Mecanismos de sincronización, Paralelo "A"
Sincronización en Solaris Solaris implementa mútex adaptativo para proteger el acceso a todos los elementos críticos. En un sistema multiprocesador un mútex adaptativo se inicia como un semáforo estándar, implementado como un cerrojo de bucle sin fin. Cuando los datos están bloqueados, el mútex primeramente lo que hace es comprobar se el cerrojo está mantenido por una hebra que se está ejecutando concurrentemente en otra CPU, y se es así la hebra actual ejecuta un bucle sin fin mientras espera a que el bloqueo esté disponible, pero si la hebra que mantiene el cerrojo no está en ejecución, entonces la hebra actual se bloquea hasta que se libera el cerrojo. Este estado de bloque es para que no se ejecute en un bucle sin fin, ya que probablemente el cerrojo no se libere pronto. En los sistemas monoprocesador, la hebra que mantiene el cerrojo nunca estará ejecutándose cuando otra hebra compruebe el cerrojo, ya que sólo puede haber una hebra ejecutándose cada vez, aquí las hebras siempre pasan en un estado durmiente. En Solaris se usa el mútex adaptativo sólo para proteger los datos a los que se accede mediante segmentos de código cortos, máximo unos cientos de instrucciones, si es más largo la solución sería muy ineficiente. Para éstos segmentos largos se usan variables de condición y los semáforos, se el cerrojo ya está en uso, la hebra ejecuta una operación de espera y pasa a estado durmiente. Cuando otra hebra libere el cerrojo, ejecutará una operación signal dirigida a la siguiente hebra durmiente de la cola.
También se usan bloqueos lector-escritor se usan para proteger aquellos datos a los que se accede frecuentemente, pero que por lo general se usan en el modo sólo lectura. Solaris utiliza colas de bloqueos para orenar la lista de hebras en espera de adquirir un mútex adaptativo o un cerrojo lector-escritor. Una cola de bloqueos es una estructura de coa que contiene las hebras que están a la espera de adquirir un cierto cerrojo.
Sincronización en Windows XP Windows XP es un kernel multihebra, que proporciona soporte para aplicaciones en tiempo real y múltiples procesadores. En Windows XP cuando se accede a un recurso global en un sistema monoprocesador, se enmascara temporalmente las interrupciones de todas las rutinas de tratamiento de interrupción que también puedan acceder al recurso global. En un sistema multiprocesador protege el acceso a los recursos globales utilizando los bloqueos basados en bucles sin fin. Para la sincronización de hebras fuera del kernel, proporciona objetos despachadores, de esa manera las hebras se sincronizan empleando diferentes mecanismos compartidos requiriendo que una hebra adquiera la propiedad de mútex para acceder a los datos y libere dicha propiedad cuando termine. Los sucesos pueden notificar a una hebra en espera que una condición deseada se ha producido. Los temporizadores se emplean para notificar a una o varias hebras que ha trascurrido un determinado período de tiempo. Los objetos despachadores pueden estar en estado señalizado o no señalizado. Un estado señalizado indica que el objeto está disponible y que una hebra no se bloqueará cuando adquiera el objeto. Un estado no señalizado indica que el objeto no está disponible y que una hebra se bloqueará cuando intente adquirir el objeto.
Sincronización en Linux Anteriormente en Linux no podía se desalojado de ninguna manera un proceso que se esté ejecutando en modo kernel, o sea que era un kernel no apropiativo, pero actualmente es apropiativo, de tal manera que sí puede ser desalojada una tarea que se esté ejecutando en modo kernel. El kernel de Linux proporciona bloqueos mediante bucles sin fin y semáforos, así como versiones lector-escritor de éstos bloqueos para establecer bloqueos en el kernel. En una máquina SMP, se hace uso de bucles sin fin, y el kernel se diseña de modo que dicho tipo de bloqueo se mantenga sólo durante períodos de tiempo cortos. En las máquinas monoprocesador, se reemplazan los bloqueos de bucle sin fin por un mecanismo de activación y desactivación de la función de apropiación en el kernel.
Linux proporciona llamadas al sistema para activar y desactivar los mecanismos de desalojo del kernel, estas son: preempt_disable(), preempt_enable(). El kernel no es desalojable si hay una tarea modo kernel que esté manteniendo un bloqueo.
Sincronización en Pthreads Pthreads proporciona cerrojos mútex, variables de condición y cerrojos de lectura-escritura para la sincronización de gebras. Todos esto está disponible en una API para los programadores y no forma parte de ningún kernel. Los cerrojos mútex proporcionan una técnica fundamental de sincronización de procesos, se usan para proteger las secciones críticas de código, es decir, una hebra adquiere el cerrojo antes de entrar en una sección crítica y lo libera al salir de la misma. Muchos sistemas que usan Pthreads también proporcionan semáforos, aunque éstos no forman parte de del estándar pthreads, otras extensiones también incluyen cerrojos mediante bucle sin fin.
Nos podemos dar cuenta que cada sistema operativo tiene su particularidad para la sincronización de procesos, sin embargo todos tienen mucho en común, y esto es las técnicas que utilizan, claro que cada uno los utiliza en las momentos que han considerado oportuno los desarrolladores del SO y además con sus propios métodos, pero lo que todo buscan en minimizar los costes por consumo de recursos. Por: 28-04-2009 por fabricomaldonado |
Categorías asociadas: Mecanismos de sincronización
<!– /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0; mso-font-charset:2; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:0 268435456 0 0 -2147483648 0;} @font-face {font-family:”Cambria Math”; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:”"; margin-top:0cm; margin-right:0cm; margin-bottom:10.0pt; margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:”Calibri”,”sans-serif”; mso-fareast-font-family:Calibri; mso-bidi-font-family:”Times New Roman”; mso-fareast-language:EN-US;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; margin-top:0cm; margin-right:0cm; margin-bottom:10.0pt; margin-left:36.0pt; mso-add-space:auto; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:”Calibri”,”sans-serif”; mso-fareast-font-family:Calibri; mso-bidi-font-family:”Times New Roman”; mso-fareast-language:EN-US;} p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:36.0pt; margin-bottom:.0001pt; mso-add-space:auto; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:”Calibri”,”sans-serif”; mso-fareast-font-family:Calibri; mso-bidi-font-family:”Times New Roman”; mso-fareast-language:EN-US;} p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:36.0pt; margin-bottom:.0001pt; mso-add-space:auto; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:”Calibri”,”sans-serif”; mso-fareast-font-family:Calibri; mso-bidi-font-family:”Times New Roman”; mso-fareast-language:EN-US;} p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0cm; margin-right:0cm; margin-bottom:10.0pt; margin-left:36.0pt; mso-add-space:auto; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:”Calibri”,”sans-serif”; mso-fareast-font-family:Calibri; mso-bidi-font-family:”Times New Roman”; mso-fareast-language:EN-US;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:”Times New Roman”; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;} .MsoPapDefault {mso-style-type:export-only; margin-bottom:10.0pt; line-height:115%;} @page Section1 {size:612.0pt 792.0pt; margin:70.85pt 3.0cm 70.85pt 3.0cm; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:709231606; mso-list-template-ids:887533600;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt; mso-ansi-font-size:10.0pt; font-family:Symbol;} @list l1 {mso-list-id:1173229869; mso-list-template-ids:-160521760;} @list l1:level1 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt; mso-ansi-font-size:10.0pt; font-family:Symbol;} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} –>
Por: Fabricio Maldonado Sincronización en WINDOWS XP
· Usa máscaras de interrupción para proteger el acceso a recursos globales en mono-procesadores. Un evento actúa de forma similar a una variable de condición. Provee de dispatcher objetos los cuales pueden actuar como ya sea como semáforos contadores o binarios · Utiliza bucles sin fin únicamente para proteger segmentos de código cortos, además de que una hebra nunca será desalojada mientras mantenga un cerrojo basado en un bucle sin fin. · Los objetos despachadores pueden estar en un estado señalizado o no señalizado. Donde un objeto señalizado indica que el objeto está disponible y que el objeto no se bloqueara cuando se adquiera el objeto. Sincronización en LINUX El kernel de Linux proporciona bloqueos mediante bucles sin fin y semáforos. Los bloqueos mediante el uso sin fin se usan en el kernel solo cuando el bloqueo se mantiene durante un periodo de tiempo corto. Cuando sea necesario mantener un bloqueo durante un periodo de tiempo largo, resulta más apropiado para utilizar semáforos. Proporciona bloqueos mediante bucles sin fin y semáforos; así como versiones de lector escritor para establecer bloqueos del kernel. Pero en las maquinas de un solo procesador en lugar de mantenerse un bloqueo de un bucle sin fin, el kernel desactiva el mecanismo de apropiación, y el proceso de liberación del bloqueo se sustituye por una reactivación del mecanismo de apropiación. Los bloqueos mediante el uso sin fin se usan en el kernel solo cuando el bloqueo se mantiene durante un periodo de tiempo corto. Cuando sea necesario mantener un bloqueo durante un periodo de tiempo largo, resulta más apropiado para utilizar semáforos. La sincronización en Linux puede mostrar mejor rendimiento ya que son independientes sus proceso se basa en deshabilitar la interrupción para secciones críticas pequeñas. Sincronización en Pthreads Es independiente del Soy provee de: variables de condición, locks mutex, además incluye locks de tipo lectura – escritura o spin locks.
Proporciona cerrojos mutex, variables de condición y cerrojos de lectura escritura para la sincronización de las hebras. Se caracteriza por que precisamente esta API está disponible para los programadores mas no para ningún kernel. Los cerrojos mutex representan quienes representan una técnica fundamental de sincronización en Pthreads. Sincronización en SOLARIS Implementa varios tipos de candados para soportar multi-tarea, multi-threading y multiprocesamiento. Usa mutexes adaptivos para proteger datos en segmentos pequeños. También con variables condicionales y candados de tipo lectores-escritores para secciones largas. Proporciona mutéx adaptativos, variables de condición, semáforos, bloqueos o cerrojos lector escritor, y colas de bloqueos. Utiliza mutex adaptativos para proteger datos a los cuales se accede mediante segmentos de código cortos; pero cuando estos son más largos se prefiere el uso de los semáforos y las variables de condición. Los bloqueos lector escritor son usados con el fin de proteger aquellos datos a los cuales se accede con frecuencia, pero que habitualmente solo se usan en modo de lectura. Por: 23-04-2009 por Jhonny Zaruma |
Categorías asociadas: Mecanismos de sincronización, Paralelo "A"
Sincronización en WINDOWS XP
Sincronización en LINUX
Sincronización en Pthreads
Sincronización en SOLARIS Por: 21-04-2009 por licho |
Categorías asociadas: Mecanismos de sincronización, Paralelo "A"
SOLARIS Implementa varios tipos de candados para soportar multi-tarea, multi-threading y multiprocesamiento, también Usa turnstiles para ordenar la lista de hebras esperando por un mutex adaptivo o candado lector-escritor. Usa mutex adaptivos para proteger datos en segmentos pequeños.
WINDOWS XP Usa máscaras de interrupción para proteger el acceso a recursos globales en mono-procesadores. Un evento actúa de forma similar a una variable de condición. Provee de dispatcher objects los cuales pueden actuar como ya sea como semáforos contadores o binarios LINUX Deshabilita interrupción para secciones críticas pequeñas. Linux prove: semáforos spin locks. Pthreads. Es independiente del Soy provee de: variables de condición, locks mutex, además incluye locks de tipo lectura – escritura o spin locks. Por: 21-04-2009 por jhoanita |
Categorías asociadas: Mecanismos de sincronización, Paralelo "A"
Nombre: Jhoana María Rojas Granda SINCRONIZACION DE PROCESOS Un proceso cooperativa es aquel que puede afectar o verse afectado por otros procesos que estén ejecutándose en el sistema. Los procesos cooperativos pueden compartir directamente un espacio de direcciones lógico o compartir los datos solo a través de archivos o mensajes. El problema de la sección critica Considere un sistema que consta de n procesos (P0, P1, ….Pn-1), cada proceso tiene un segmento de código, llamado sección critica, en el que el proceso puede modificar variables comunes, actualizar una tabla, escribir en un archivo. La característica importante del sistema es que, cuando un proceso esta ejecutando su sección critica, ningún otro proceso puede ejecutar su correspondiente sección crítica, es decir dos procesos no pueden ejecutar su sección crítica al mismo tiempo. El problema de la sección critica consiste en diseñar un protocolo que los procesos puedan usar para cooperar de esta forma, cada proceso debe solicitar permiso para entrar en su sección critica, la sección de código que implementa esta solicitud es la sección de entrada. La sección crítica puede ir seguida de una sección de salida. Cualquier solución al problema de la sección crítica deberá satisfacer los tres requisitos: Exclusión mutua.- Si el proceso P esta ejecutándose en una sección crítica, los demás procesos no pueden estar ejecutando sus secciones críticas. Progreso.- Si ningún proceso esta ejecutándose su sección crítica y algunos procesos desean entrar en sus correspondientes secciones. Espera limitada.- Existe un límite en el número de veces que se permite que otros procesos entren en sus secciones críticas después de que un proceso haya hecho una solicitud para entrar en su sección. Si dos procesos abrieran archivos simultáneamente, las actualizaciones de la lista podrían llevar a una condición de carrera, otras estructuras de datos del kernel propensas a posibles condiciones de carrera son aquellas empleadas para controlar la asignación de memoria, las listas de procesos y para gestionar las interrupciones. Es responsabilidad de los desarrolladores del kernel asegurar que el sistema operativo este libre de tales condiciones de carrera. Se usan dos métodos generales para gestionar las secciones críticas en los sistemas operativos, los kernel apropiativos y los kernel no apropiativos. Un kernel apropiativo permite que un proceso sea desalojado mientras se esta ejecutando en modo kernel, un kernel no apropiativo no permite que un proceso que se este ejecutando en modo kernel sea desalojado, el proceso en modo kernel se ejecutara hasta que salga de dicho modo, hasta que se bloquee o hasta que ceda voluntariamente el control de la CPU. Solución de Peterson La solución de Peterson se restringe a dos procesos que van alternando la ejecución de sus secciones críticas y de sus secciones restantes. Los procesos se numeran como P0 y P1. Por conveniencia, cuando hablemos de Pi, usaremos Pj para referirnos al otro proceso, es decir j es igual a 1-i. La solución de Peterson requiere que los dos procesos compartan dos elementos de datos:
Int turn; Boolean flag
La variable turn indica que proceso va a entrar en su sección crítica. La matriz flag se usa para indicar si un proceso esta preparado para entrar en su sección critica. Ahora vamos a demostrar que esta solución es correcta. Necesitamos demostrar que: 1. La exclusión mutua se conserva. 2. El requisito de progreso se satisface. 3. El requisito de espera limitada se cumple.
Hardware de Sincronización En general, podemos afirmar que cualquier solución al problema de la sección crítica requiere una herramienta muy simple, un cerrojo. Es decir, un proceso debe adquirir un cerrojo antes de entrar en una sección crítica y liberarlo cuando salga de la misma. El soporte hardware puede facilitar cualquier tarea de programación y mejorar la eficiencia del sistema.
Semáforos La diversas soluciones hardware al problema de la sección crítica, basadas en las instrucciones TestAndSet() y Swap(). Un semáforo S es una variable entera a la que, dejando aparte la inicialización, solo se accede mediante dos operaciones atómicas estándar wait() y signal(). Utilización Los sistemas operativos diferencian a menudo entre semáforos contadores y semáforos binarios. El valor de un semáforo contador puede variar en un dominio no restringido, mientras que el valor de un semáforo binario solo puede ser 0 o 1. En algunos sistemas, los semáforos binarios se conocen como cerrojos mutex, ya que son cerrojos que proporcionan exclusión mutua. Podemos usar semáforos binarios para abordar el problema de la sección crítica en el caso de múltiples procesos. Cuando la cuenta del semáforo llega a 0, todos los recursos estarán en uso.
Implementación
La principal desventaja de la definición de semáforo dada aquí es que requiere una espera activa. Mientras un proceso esta en su sección critica, cualquier otro proceso que intente entrar en su sección critica debe ejecutar continuamente un bucle en el código de entrada. La espera activa desperdicia ciclos de CPU que algunos otros procesos podrían usar de forma productiva. Este tipo de semáforo también se denomina cerrojo mediante bucle sin fin, ya que el proceso permanece en un bucle sin fin en espera de adquirir un cerrojo. Un proceso bloqueado, que esta esperando en un semáforo S, debe reiniciarse cuando algún otro proceso ejecuta una operación signal(). El proceso se reinicia mediante una operación wakeup(), que cambia al proceso de estado de espera al estado de preparado. La lista de procesos en espera puede implementarse fácilmente mediante un campo de enlace en cada bloque de control de proceso. Cada semáforo contiene un valor entero y un puntero garantice un tiempo de espera limitado consiste en usar una cola FIFO, donde el semáforo contenga punteros a ambos extremos de la cola. El aspecto critico de los semáforos es que se deben ejecutar atómicamente, tenemos que garantizar que dos procesos no puedan ejecutar al mismo tiempo sendas operaciones wait() y signal() sobre el mismo semáforo.
Interbloqueos e inanición La implementación de un semáforo con una cola de espera puede dar lugar a una situación en la que dos o más procesos estén esperando indefinidamente a que se produzca un suceso que solo puede producirse como consecuencia de las operaciones efectuadas por otro de los procesos en espera. El suceso en cuestión es la ejecución de una operación signal(). Cuando se llega a un estado así, se dice que estos procesos se han interbloqueado. Los sucesos que más nos interesan aquí son los de adquisición y liberación de recursos, pero también hay otros tipos de sucesos que pueden dar lugar a interbloqueos. Otro problema relacionado con los interbloqueos es el del bloqueo indefinido o muerte por inanición, una situación en la que algunos procesos esperan de forma indefinida dentro del semáforo. El bloqueo indefinido puede producirse si añadimos y eliminamos los procesos a la lista asociada con el semáforo utilizando un esquema LIFO.
Problemas clásicos de sincronización Problema del búfer limitado El problema del buffer limitado se ha presentado habitualmente se utiliza para ilustrar la potencia de las primitivas de sincronización. Podemos interpretar este código como un productor que genera los búferes llenos para el consumidor o como un consumidor que genera búferes vacios para el productor.
Problema de los lectores-escritores Algunos de estos procesos pueden simplemente querer leer la base de datos, mientras que otros pueden desear actualizarla. Diferenciamos entre estos dos tipos de procesos denominando a los primeros lectores y a los otros escritores. Para asegurar que estos problemas no afloren, requeriremos que los procesos escritores tengan acceso exclusivo a la base de datos compartida. Este problema de sincronización se denomina problema de los lectores y escritores. Desde que se lo estableció originalmente, este problema se ha utilizado para probar casi todas las nuevas primitivas de sincronización. El problema de los lectores y escritores presenta diversas variantes, todas las cuales utilizan prioridades. El más sencillo, conocido como primer problema de los lectores-escritores, requiere que ningún lector se mantenga en espera a menos que un escritor haya obtenido ya permiso para utilizar el objeto compartido. Una solución a cualquiera de estos problemas puede dar como resultado un problema de inanición. En el primer caso, los escritores pueden bloquearse indefinidamente en el segundo caso, son los lectores los que pueden morir de inanición. Por esta razón, se han propuesto otras variantes del problema. Los cerrojos lector-escritor resultan especialmente útiles en las situaciones siguientes: - En aquellas aplicaciones en las que sea fácil identificar que procesos solo desean leer los datos compartidos. - En aquellas aplicaciones que tengan mas procesos lectores que escritores. Problema de la cena de los filósofos El problema de la cena de los filósofos se considera un problema clásico de sincronización, no por su importancia practica ni porque los informáticos tengan aversión a los filósofos, sino porque es un ejemplo de una amplia clase de problemas de control de concurrencia. Es una representación sencilla de la necesidad de repartir varios recursos entre varios procesos de una forma que no se produzcan interbloqueos ni bloqueos indefinidos. Una solución sencilla consiste en representar cada palillo mediante un semáforo. Un filosofo intenta hacerse con un palillo ejecutando una operación wait() en dicho semáforo y libera sus palillos ejecutando la operación signal() en los semáforos adecuados, por tanto, los datos compartidos son donde todos los elementos de palillo se inicializan con el valor 1.
Monitores Aunque los semáforos proporcionan un mecanismo adecuado y efectivo para el proceso de sincronización, un uso incorrecto de los mismos puede dar lugar a errores de temporización que son difíciles de detectar, dado que estos errores solo ocurren si tienen lugar algunas secuencias de ejecución concretas y estas secuencias no siempre se producen.
Utilización Un tipo, o un tipo abstracto de datos, agrupan una serie de datos privados con un conjunto de métodos públicos que se utilizan para operar sobre dichos datos. Un tipo monitor tiene un conjunto de operaciones definidas por el programador que gozan de la característica de exclusión mutua dentro del monitor. La representación de un tipo monitor no puede ser utilizada directamente por los diversos procesos. Así, un procedimiento definido dentro de un monitor solo puede acceder a las variables declaradas localmente dentro del monitor y a sus parámetros formales. De forma similar, a las variables locales de un monitor solo un proceso este activo cada vez dentro del monitor. Existen dos posibilidades: 1. Señalizar y esperar.- P espera hasta que Q salga del monitor o espere a que se produzca otra condición. 2. Señalizar y continuar.- Q espera hasta que P salga del monitor o espere a que se produzca otra condición.
Sincronización en Windows Xp:
Windows Xp protege el acceso a los recursos globales utilizando bloqueos basados en bucles sin fin. Para la sincronización de hebras fuera del kernel, Windows Xp proporciona objetos despachadores, utilizando un objeto despachador, las hebras de sincronización empleando diferentes mecanismos, incluyendo mútex, semáforos, sucesos y temporizadores.
El sistema protege los datos compartidos requiriendo que una hebra adquiera la propiedad de un mútex para acceder a los datos y libere dicha propiedad cuando termine. Los sucesos son similares a las variables de condición, es decir pueden notificar a una hebra en espera que una condición deseada se ha producido.
Sincronización en Windows Linux:
El kernel de Linux proporciona bloqueos mediante bucles sin fin y semáforos para establecer bloqueos en kernel. En una maquina SMP, el mecanismo fundamental de bloqueo es el que se basa en el uso de bucles sin fin, y el kernel se diseña de modo que dicho tipo de bloqueo se mantenga durante periodos de tiempo corto.
Las maquinas con un solo procesador, los bloqueos mediante bucle sin fin no resultan apropiados y se reemplazan por un mecanismo de activación y desactivación de la función de apropiación en el kernel.
Sincronización en Windows Pthreads:
Este proporciona cerrojos mútex, las variables de condición y cerrojos de lectura-escritura para la sincronización de hebras. Esta API está disponible para los programadores y no forma parte de ningún kernel.
Los cerrojos mútex representan la técnica fundamental de sincronización utilizada en Pthreads. Un cerrojo mutex se utiliza para proteger las secciones críticas de código.
Por: 21-04-2009 por acmedina |
Categorías asociadas: Mecanismos de sincronización
Sincronización en Windows XP Windows XP proporciona objetos despachadores. Utilizando un objeto despachador, las hebras se sincronizan empleando diferentes mecanismos, incluyendo mútex, semáforos, sucesos y temporizadores. El sistema protege los datos compartidos requiriendo que una hebra adquiera la propiedad de un mútex para acceder a los datos y libere dicha propiedad cuando termine. Usa máscaras de interrupción para proteger el acceso a recursos globales en mono-procesadores. Un evento actúa de forma similar a una variable de condición.
Sincronización en Solaris Un mútex adaptivo protege el acceso a todos los elementos de datos críticos. En un sistema multiprocesador, un mútex adaptativo se inicia como un semáforo estándar, implementando como un cerrojo de bucle sin fin. Los bloqueos lector escritor con el fin de proteger aquellos datos a los cuales se accede con frecuencia, pero q habitualmente sola se usan en modo de lectura. Usados por su alto coste de implementación sola en secciones de código largas. Sincronización en Linux El kernel de Linux proporciona bloqueos mediante bucles sin fin y semáforos. Los bloqueos mediante el uso sin fin se usan en el kernel solo cuando el bloqueo se mantiene durante un periodo de tiempo corto. Cuando sea necesario mantener un bloqueo durante un periodo de tiempo largo, resulta más apropiado para utilizar semáforos.
Por: 21-04-2009 por rcvalladolid |
Categorías asociadas: Mecanismos de sincronización, Uncategorized
Roberto Valladolid. SINCRONIZACION DE PROCESOS. Un proceso cooperativa es aquel que puede afectar o verse afectado por otros procesos que estén ejecutándose en el sistema. Considere un sistema que consta de n procesos, cada proceso tiene un segmento de código, llamado sección critica, en el que el proceso puede modificar variables comunes, actualizar una tabla, escribir en un archivo. La característica importante del sistema es que, cuando un proceso esta ejecutando su sección critica, ningún otro proceso puede ejecutar su correspondiente sección critica, es decir dos procesos no pueden ejecutar su sección critica al mismo tiempo. El problema de la sección critica consiste en diseñar un protocolo que los procesos puedan usar para cooperar de esta forma, cada proceso debe solicitar permiso para entrar en su sección critica, la sección de código que implementa esta solicitud es la sección de entrada. La sección crítica puede ir seguida de una sección de salida. Exclusión mutua.- Si el proceso P esta ejecutándose en una sección crítica, los demás procesos no pueden estar ejecutando sus secciones críticas. Espera limitada.- Existe un límite en el número de veces que se permite que otros procesos entren en sus secciones críticas después de que un proceso haya hecho una solicitud para entrar en su sección. Se usan dos métodos generales para gestionar las secciones críticas en los sistemas operativos, los kernel apropiativos y los kernel no apropiativos. Un kernel apropiativo permite que un proceso sea desalojado mientras se esta ejecutando en modo kernel, un kernel no apropiativo no permite que un proceso que se este ejecutando en modo kernel sea desalojado, el proceso en modo kernel se ejecutara hasta que salga de dicho modo, hasta que se bloquee o hasta que ceda voluntariamente el control de la CPU. Solucion de Peterson: La solución de Peterson se restringe a dos procesos que van alternando la ejecución de sus secciones críticas y de sus secciones restantes. Los procesos se numeran como P0 y P1. Por conveniencia, cuando hablemos de Pi, usaremos Pj para referirnos al otro proceso, es decir j es igual a 1-i. Ahora vamos a demostrar que esta solución es correcta. Necesitamos demostrar que: 1. La exclusión mutua se conserva. Hardware de Sincronización. En general, podemos afirmar que cualquier solución al problema de la sección crítica requiere una herramienta muy simple, un cerrojo. Es decir, un proceso debe adquirir un cerrojo antes de entrar en una sección crítica y liberarlo cuando salga de la misma. Semáforos: La diversas soluciones hardware al problema de la sección crítica, basadas en las instrucciones TestAndSet() y Swap(). Utilización: Los sistemas operativos diferencian a menudo entre semáforos contadores y semáforos binarios. El valor de un semáforo contador puede variar en un dominio no restringido, mientras que el valor de un semáforo binario solo puede ser 0 o 1. Podemos usar semáforos binarios para abordar el problema de la sección critica en el caso de múltiples procesos. Cuando la cuenta del semáforo llega a 0, todos los recursos estarán en uso. Implementación: La principal desventaja de la definición de semáforo dada aquí es que requiere una espera activa. Mientras un proceso esta en su sección critica, cualquier otro proceso que intente entrar en su sección critica debe ejecutar continuamente un bucle en el código de entrada. La espera activa desperdicia ciclos de CPU que algunos otros procesos podrían usar de forma productiva. Este tipo de semáforo también se denomina cerrojo mediante bucle sin fin, ya que el proceso permanece en un bucle sin fin en espera de adquirir un cerrojo. Un proceso bloqueado, que esta esperando en un semáforo S, debe reiniciarse cuando algún otro proceso ejecuta una operación signal(). El proceso se reinicia mediante una operación wakeup(), que cambia al proceso de estado de espera al estado de preparado. La lista de procesos en espera puede implementarse fácilmente mediante un campo de enlace en cada bloque de control de proceso. Cada semáforo contiene un valor entero y un puntero garantice un tiempo de espera limitado consiste en usar una cola FIFO, donde el semáforo contenga punteros a ambos extremos de la cola. Interbloqueos e inanición. La implementación de un semáforo con una cola de espera puede dar lugar a una situación en la que dos o mas procesos estén esperando indefinidamente a que se produzca un suceso que solo puede producirse como consecuencia de las operaciones efectuadas por otro de los procesos en espera. El suceso en cuestión es la ejecución de una operación signal(). Cuando se llega a un estado así, se dice que estos procesos se han interbloqueado. Otro problema relacionado con los interbloqueos es el del bloqueo indefinido o muerte por inanición, una situación en la que algunos procesos esperan de forma indefinida dentro del semáforo. El bloqueo indefinido puede producirse si añadimos y eliminamos los procesos a la lista asociada con el semáforo utilizando un esquema LIFO. Problemas clásicos de sincronización. Problema del búfer limitado: El problema del buffer limitado se ha presentado habitualmente se utiliza para ilustrar la potencia de las primitivas de sincronización. Problema de los lectores-escritores: Algunos de estos procesos pueden simplemente querer leer la base de datos, mientras que otros pueden desear actualizarla. Diferenciamos entre estos dos tipos de procesos denominando a los primeros lectores y a los otros escritores. Para asegurar que estos problemas no afloren, requeriremos que los procesos escritores tengan acceso exclusivo a la base de datos compartida. Este problema de sincronización se denomina problema de los lectores y escritores. Desde que se lo estableció originalmente, este problema se ha utilizado para probar casi todas las nuevas primitivas de sincronización. El problema de los lectores y escritores presenta diversas variantes, todas las cuales utilizan prioridades. Una solución a cualquiera de estos problemas pueden dar como resultado un problema de inanición. En el primer caso, los escritores pueden bloquearse indefinidamente en el segundo caso, son los lectores los que pueden morir de inanición. Por esta razón, se han propuesto otras variantes del problema. Problema de la cena de los filósofos: El problema de la cena de los filósofos se considera un problema clásico de sincronización, no por su importancia practica ni porque los informáticos tengan aversión a los filósofos, sino porque es un ejemplo de una amplia clase de problemas de control de concurrencia. Es una representación sencilla de la necesidad de repartir varios recursos entre varios procesos de una forma que no se produzcan interbloqueos ni bloqueos indefinidos. Una solución sencilla consiste en representar cada palillo mediante un semáforo. Un filosofo intenta hacerse con un palillo ejecutando una operación wait() en dicho semáforo y libera sus palillos ejecutando la operación signal() en los semáforos adecuados, por tanto, los datos compartidos son donde todos los elementos de palillo se inicializan con el valor 1. La representación de un tipo monitor no puede ser utilizada directamente por los diversos procesos. Así, un procedimiento definido dentro de un monitor solo puede acceder a las variables declaradas localmente dentro del monitor y a sus parámetros formales. De forma similar, a las variables locales de un monitor solo un proceso este activo cada vez dentro del monitor. 1. Señalizar y esperar.- P espera hasta que Q salga del monitor o espere a que se produzca otra condición. Sincronización en Windows Xp: El sistema protege los datos compartidos requiriendo que una hebra adquiera la propiedad de un mútex para acceder a los datos y libere dicha propiedad cuando termine. Los sucesos son similares a las variables de condición, es decir pueden notificar a una hebra en espera que una condición deseada se ha producido. Sincronización en Windows Linux: El kernel de Linux proporciona bloqueos mediante bucles sin fin y semáforos para establecer bloqueos en kernel. En una maquina SMP, el mecanismo fundamental de bloqueo es el que se basa en el uso de bucles sin fin, y el kernel se diseña de modo que dicho tipo de bloqueo se mantenga durante periodos de tiempo corto. Sincronización en Windows Pthreads: Este proporciona cerrojos mútex, las variables de condición y cerrojos de lectura-escritura para la sincronización de hebras. Esta API está disponible para los programadores y no forma parte de ningún kernel. Por: 21-04-2009 por edcalderon |
Categorías asociadas: Mecanismos de sincronización
Por: Eylin Calderón
Por: 21-04-2009 por »¦«EÐU@®ÐO»¦« |
Categorías asociadas: Mecanismos de sincronización, Paralelo "A"
Eduardo Burgasí
Sincronización en Solaris
Proporciona mutéx adaptativos, variables de condición, semáforos, bloqueos o cerrojos lector escritor, y colas de bloqueos. Utiliza mutex adaptativos para proteger datos a los cuales se accede mediante segmentos de código cortos; pero cuando estos son más largos se prefiere el uso de los semáforos y las variables de condición. Los bloqueos lector escritor son usados con el fin de proteger aquellos datos a los cuales se accede con frecuencia, pero q ue habitualmente solo se usan en modo de lectura.
Usados por su alto coste de implementación sola en secciones de código largas.
Las colas de bloqueo que permiten el ordenamiento de las hebras que se encuentran en espera de adquirir un mutex adaptativo o un cerrojo lector escritor. Este sistema proporciona una hebra kernel por cada cola de bloqueo. Utilizando los cerrojos frecuentemente.
Sincronización en Windows XP
Es un kernel multihebra que proporciona soporte para aplicaciones en tiempo real y múltiples procesadores. Utiliza bucles sin fin, únicamente para proteger segmentos de código cortos, además de que una hebra nunca será desalojada mientras mantenga un cerrojo basado en un bucle sin fin. Las hebras fuera del kernel este utiliza los objetos despachadores, utilizando mutex, semáforos, sucesos y temporizadores. Los objetos despachadores pueden estar en un estado señalizado o no señalizado.
Donde un objeto señalizado indica que el objeto está disponible y que el objeto no se bloqueara cuando se adquiera el objeto. Y un estado no señalizado indica que un objeto no está disponible y que una hebra se bloqueara cuando intente adquirir un objeto.
Sincronización en Linux
Proporciona bloqueos mediante bucles sin fin y semáforos; así como versiones de lector escritor para establecer bloqueos del kernel.
Pero en las maquinas de un solo procesador en lugar de mantenerse un bloqueo de un bucle sin fin, el kernel desactiva el mecanismo de apropiación, y el proceso de liberación del bloqueo se sustituye por una reactivación del mecanismo de apropiación.
Los bloqueos mediante el uso sin fin se usan en el kernel solo cuando el bloqueo se mantiene durante un periodo de tiempo corto. Cuando sea necesario mantener un bloqueo durante un periodo de tiempo largo, resulta más apropiado para utilizar semáforos.
Sincronización en Pthreads
Proporciona cerrojos mutex, variables de condición y cerrojos de lectura escritura para la sincronización de las hebras. Se caracteriza por que precisamente esta API está disponible para los programadores mas no para ningún kernel. Los cerrojos mutex representan quienes representan una técnica fundamental de sincronización en Pthreads. Al igual que otros sistemas operativos funcionan con semáforos, cerrojos de lectura escritura, variables de condición. Incluso pueden incluir cerrojos de bucle sin fin.
Por: 21-04-2009 por wortega |
Categorías asociadas: Mecanismos de sincronización, Paralelo "A"
Walter Ortega Sincronización en Solaris Utiliza mutex para proteger datos a los cuales se accede mediante segmentos de código cortos; pero cuando estos son más largos se prefiere el uso de los semáforos y las variables de condición. Solaris usa varios tipos de candados para poder soportar mutitarea, multithreading y multiprocesamiento, usa variables condicionales y candados de tipo lectores-escritores para secciones largas. Sincronización en Windows XP Utiliza bucles sin fin únicamente para proteger segmentos de código cortos, además de que una hebra nunca será desalojada mientras mantenga un cerrojo basado en un bucle sin fin. Los objetos despachadores pueden estar en un estado señalizado o no señalizado. Donde un objeto señalizado indica que el objeto está disponible y que el objeto no se bloqueara cuando se adquiera el objeto. Sincronización en Linux La sincronización en Linux puede mostrar mejor rendimiento ya que son independientes sus proceso se basa en deshabilitar la interrupción para seccion. Este sistema proporciona bloqueos mediante bucles sin fin y semáforos; así como versiones de lector escritor para establecer bloqueos del kernel. Sincronización en Pthreads Proporciona cerrojos mutex, variables de condición y cerrojos de lectura escritura para la sincronización de las hebras. Se caracteriza por que precisamente esta API está disponible para los programadores mas no para ningún kernel. Al igual que otros sistemas operativos funcionan con semáforos, cerrojos de lectura escritura, variables de condición.
|
|
Blog Multiusuario by Gestion del Conocimiento is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Ecuador License.
Based on a work at www.utpl.edu.ec..