<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="es">
		<id>https://1984.lsi.us.es/wiki-ssoo/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Danescsan</id>
		<title>Wiki de Sistemas Operativos - Contribuciones del usuario [es]</title>
		<link rel="self" type="application/atom+xml" href="https://1984.lsi.us.es/wiki-ssoo/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Danescsan"/>
		<link rel="alternate" type="text/html" href="https://1984.lsi.us.es/wiki-ssoo/index.php/Especial:Contribuciones/Danescsan"/>
		<updated>2026-05-11T20:33:02Z</updated>
		<subtitle>Contribuciones del usuario</subtitle>
		<generator>MediaWiki 1.29.0</generator>

	<entry>
		<id>https://1984.lsi.us.es/wiki-ssoo/index.php?title=P%C3%A1gina_con_listado_de_personas_que_han_contribuido&amp;diff=2435</id>
		<title>Página con listado de personas que han contribuido</title>
		<link rel="alternate" type="text/html" href="https://1984.lsi.us.es/wiki-ssoo/index.php?title=P%C3%A1gina_con_listado_de_personas_que_han_contribuido&amp;diff=2435"/>
				<updated>2012-01-28T16:41:27Z</updated>
		
		<summary type="html">&lt;p&gt;Danescsan: mi nombre de usuario&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A continuación, la lista de usuarios/as de la Universidad de Sevilla que han contribuido a la wiki. Si ponéis tu usuario/a estás solicitando al profesor que evalúe tus contribuciones a la wiki para la subida de notas de hasta 2 puntos posible:&lt;br /&gt;
&lt;br /&gt;
* luigarhor&lt;br /&gt;
* rafperper&lt;br /&gt;
* sergaralo&lt;br /&gt;
* josalgrod1&lt;br /&gt;
* felgaroje&lt;br /&gt;
* luimunlei&lt;br /&gt;
* [https://1984.lsi.us.es/wiki-ssoo/index.php/Usuario:Lorruimor Lorruimor]&lt;br /&gt;
* albsolnog&lt;br /&gt;
* framorexp&lt;br /&gt;
* javgarang&lt;br /&gt;
* FerGuaTol&lt;br /&gt;
* jesgonbel&lt;br /&gt;
* fraperdom&lt;br /&gt;
* antdomflo&lt;br /&gt;
* antmorzam&lt;br /&gt;
* migoligon&lt;br /&gt;
* danplaseg&lt;br /&gt;
* peducemar&lt;br /&gt;
* danescsan&lt;/div&gt;</summary>
		<author><name>Danescsan</name></author>	</entry>

	<entry>
		<id>https://1984.lsi.us.es/wiki-ssoo/index.php?title=Condiciones_para_el_interbloqueo_y_estrategias_de_resoluci%C3%B3n&amp;diff=2089</id>
		<title>Condiciones para el interbloqueo y estrategias de resolución</title>
		<link rel="alternate" type="text/html" href="https://1984.lsi.us.es/wiki-ssoo/index.php?title=Condiciones_para_el_interbloqueo_y_estrategias_de_resoluci%C3%B3n&amp;diff=2089"/>
				<updated>2011-12-08T14:42:47Z</updated>
		
		<summary type="html">&lt;p&gt;Danescsan: /* Condiciones para que se produzca interbloqueo */ Corrección ortográfica&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Condiciones para que se produzca interbloqueo ==&lt;br /&gt;
&lt;br /&gt;
Según [http://en.wikipedia.org/wiki/Edward_G._Coffman,_Jr. Coffman], para que se pueda producir un interbloqueo se tienen que dar las siguientes cuatro condiciones:&lt;br /&gt;
&lt;br /&gt;
* '''Exclusión mutua''': cada recurso está asignado a un único proceso de manera exclusiva.&lt;br /&gt;
* '''Retención y espera''': los procesos que tienen, en un momento dado, recursos asignados con anterioridad, pueden solicitar nuevos recursos y esperar a que se le asignen sin liberar antes alguno de los recursos que ya tenia asignados.&lt;br /&gt;
&lt;br /&gt;
* '''No apropiación''': los recursos otorgados con anterioridad no pueden ser forzados a dejar un  proceso. El proceso que los posee debe liberarlos en forma explícita. Ni siquiera el sistema operativo puede expropiarselo.&lt;br /&gt;
&lt;br /&gt;
* '''Espera circular''': debe existir una cadena circular de dos o más procesos, cada uno de los cuales espera un recurso poseído por el siguiente miembro de la cadena. Esta condición es una consecuencia potencial de las tres primeras, es decir, dado que se producen las tres primeras condiciones, puede ocurrir una secuencia de eventos que desemboque en un círculo vicioso de espera irresoluble. &lt;br /&gt;
&lt;br /&gt;
Las tres primeras condiciones son necesarias, pero no suficientes para que exista interbloqueo. Sólo las cuatro condiciones en conjunto constituyen una condición necesaria y suficiente para el interbloqueo.&lt;br /&gt;
&lt;br /&gt;
== Estrategias ==&lt;br /&gt;
&lt;br /&gt;
Existen diversas estrategias frente a los interbloqueos, que se pueden agrupar en:&lt;br /&gt;
&lt;br /&gt;
* Omisión&lt;br /&gt;
* Detección y recuperación&lt;br /&gt;
* Prevención&lt;br /&gt;
* Predicción&lt;br /&gt;
&lt;br /&gt;
Que se detallan a continuación.&lt;br /&gt;
&lt;br /&gt;
=== Omisión ===&lt;br /&gt;
&lt;br /&gt;
Considera que la probabilidad de un interbloqueo es muy baja, de modo que se confía en que no se van a producir. Por sorprendente que parezca, los sistemas operativos modernos convencionales suelen aplicar esta estrategia. Por justificar la decisión de los fabricantes de sistemas operativos cabe incidir en que las estrategias de resolución y prevención de interbloqueos tienen un coste alto desde el punto de vista del consumo de recursos de procesamiento y memoria.&lt;br /&gt;
&lt;br /&gt;
=== Detección y Recuperación ===&lt;br /&gt;
&lt;br /&gt;
Esta estrategia permite la detección de una situación de interbloqueo y su consiguiente resolución. De entre las medidas de detección consideramos las siguientes:&lt;br /&gt;
&lt;br /&gt;
* ''Grafo de relación recursos-procesos'': Consiste en la representación gráfica de los recursos asignados a los procesos y los recursos que dichos procesos requieren para finalizar su ejecución.&lt;br /&gt;
&lt;br /&gt;
* ''Matrices de relación recursos-procesos'': Consiste en la representación matricial de los recursos asignados a los procesos y los recursos que dichos procesos requieren para finalizar su ejecución.&lt;br /&gt;
&lt;br /&gt;
Tras la detección de un interbloqueo, se pueden aplicar algunas de las siguientes estrategias para resolverlo:&lt;br /&gt;
&lt;br /&gt;
* ''Eliminación'': El sistema operativo selecciona a uno de los procesos que forma parte del interbloqueo y elimina el ciclo acabando con la ejecución de dicho proceso, si no es suficiente se eliminarán procesos hasta que se rompa el ciclo. La selección del proceso se realiza en base a un cierto criterio, por ejemplo, aquel proceso que lleve menos tiempo en ejecución o aquel que sea más voraz consumiendo recursos. Aunque parezca una medida drástica, es la empleada en sistemas operativos convencionales. Aplicar el criterio de selección y eliminar procesos cuando el número de procesos es relativamente bajo puede solucionar el interbloqueo, pero si se da un bloqueo de por ejemplo, centenares de procesos, es una situación prácticamente inmanejable.&lt;br /&gt;
&lt;br /&gt;
* ''Apropiación temporal'': Se retira la asignación de un recurso a un proceso (durante el tiempo necesario) para deshacer el interbloqueo.Por ejemplo, supongamos que el recurso es una impresora: podríamos retirarle la asignación a un proceso P1 cuando este terminase de imprimir una página, asignarle la impresora a otro proceso P2 y volver a asignársela a P1 cuando P2 haya terminado su ejecución.  &lt;br /&gt;
&lt;br /&gt;
* ''Puntos de conformidad'' o ''checkpoints'': Consiste en tomar una imagen del estado del proceso, ya sea periódicamente o a instancia del propio proceso, de manera que si se produce un interbloqueo se vuelve a un estado de la ejecución anterior. Son muy poco usados ya que tienen un elevado coste en memoria y existe la posibilidad de que un proceso permanezca indefinidamente sin progresar.&lt;br /&gt;
&lt;br /&gt;
=== Prevención ===&lt;br /&gt;
&lt;br /&gt;
La prevención apunta a una serie de estrategias que eviten el interbloqueo. Concretamente, son cuatro las estrategias de prevención posibles en base a los  principios que [http://en.wikipedia.org/wiki/Edward_G._Coffman,_Jr. Coffman] estableció como interbloqueo. Dichas estrategias son:&lt;br /&gt;
&lt;br /&gt;
* ''Supresión de exclusión mutua'': un proceso no puede tener acceso exclusivo a un recurso.&lt;br /&gt;
* ''Supresión de retención y espera'' (1ª estrategia de Havender): El proceso debe tener asignado todos los recursos necesarios al inicio y no liberarlos hasta que éste finalice. Esto presenta un inconveniente: si un recurso sólo se utiliza al final, estará ocupado durante toda la ejecución, no permitiendo ser usado por otros procesos. El aprovechamiento de recursos puede mejorarse mediante una programación más elaborada, dividiendo la ejecución del proceso en distintas fases y gestionando los recursos para cada una de ellas.&lt;br /&gt;
* ''Supresión de no apropiación'' (2ª estrategia de Havender): Si un proceso está en ejecución y no puede obtener un recurso, dicho proceso libera todos los recursos que está usando y espera a que todos los que necesita estén disponibles. Problemas: se puede perder trabajo, además de presentar una carga extra la realización de peticiones &lt;br /&gt;
* ''Supresión de espera circular'' (3ª estrategia de Havender): Si todos los recursos comunes a varios procesos se solicitan siempre en el mismo orden no se producen interbloqueos.&lt;br /&gt;
&lt;br /&gt;
=== Predicción ===&lt;br /&gt;
&lt;br /&gt;
El sistema operativo observa la evolución que siguen los procesos, y predice una posible situación de interbloqueo. Si detecta una alta probabilidad de que suceda, adopta una trayectoria de ejecución nueva para los procesos involucrados de manera que se garantice que no va a suceder un interbloqueo.&lt;/div&gt;</summary>
		<author><name>Danescsan</name></author>	</entry>

	<entry>
		<id>https://1984.lsi.us.es/wiki-ssoo/index.php?title=Monitores&amp;diff=2057</id>
		<title>Monitores</title>
		<link rel="alternate" type="text/html" href="https://1984.lsi.us.es/wiki-ssoo/index.php?title=Monitores&amp;diff=2057"/>
				<updated>2011-12-06T20:15:39Z</updated>
		
		<summary type="html">&lt;p&gt;Danescsan: /* Ejemplo del funcionamiento de una clase monitor */ Corrección en la instrucción set dentro del h2, he añadido i como parámetro&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Idea desarrollada en los años 70 Brinch-Hansen y Hoare &amp;lt;ref&amp;gt;http://java.sun.com/developer/Books/performance2/chap4.pdf&amp;lt;/ref&amp;gt;que notaron los siguientes problemas con respecto al uso de los semáforos:&lt;br /&gt;
&lt;br /&gt;
* Los semáforos son difíciles de usar. Es frecuente que el programador cometa errores al emplearlos.&lt;br /&gt;
* El compilador no asiste al programador en el desarrollo de programas concurrentes mediante semáforos, pues no ofrece ningún tipo de validación en tiempo de compilación.&lt;br /&gt;
* No hay nada que obligue a usarlos. Puede suceder que el programador los necesite y lo desconozca&lt;br /&gt;
* Son independientes del recurso compartido&lt;br /&gt;
&lt;br /&gt;
Los monitores tienen que estar integrados en el lenguaje de programación.&lt;br /&gt;
&lt;br /&gt;
== Definición ==&lt;br /&gt;
Un monitor es una estructura del lenguaje cuyas principales características son:&lt;br /&gt;
&lt;br /&gt;
* Los datos son privados.&lt;br /&gt;
* Ofrecen una serie de métodos públicos para acceder a dichos datos.&lt;br /&gt;
* En cada momento sólo puede haber un proceso activo en algún método del monitor, es decir, ejecutando código de esos métodos públicos del monitor. Seria equivalente a decir que el recurso que queremos compartir se declara como monitor. Los procesos que usan el monitor son independientes unos de otros y cuando deseen usar el recurso, llamarán a los métodos del monitor que implementen la operación que se desea ejecutar. &lt;br /&gt;
&lt;br /&gt;
Permiten organizar procesos en espera mediante:&lt;br /&gt;
&lt;br /&gt;
* Variables de condición: lista de procesos inicialmente vacía.&lt;br /&gt;
* Primitivas: ''wait(c)'', añade el proceso p invocante a c y proceso p bloquea; ''signal(c)'', selecciona a uno de los procesos en c y lo pone en preparado.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang=&amp;quot;java&amp;quot;&amp;gt;&lt;br /&gt;
&lt;br /&gt;
class recursoCompartido {&lt;br /&gt;
&lt;br /&gt;
    private int recursoCompartido;&lt;br /&gt;
    private Semaforo s = 1;&lt;br /&gt;
&lt;br /&gt;
    public int get(void){&lt;br /&gt;
        int ret;                   #1&lt;br /&gt;
        down(s);                   #2&lt;br /&gt;
        ret = recursoCompartido;   #3&lt;br /&gt;
        up(s);                     #4&lt;br /&gt;
        return ret;                #5&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public void set(int valor){&lt;br /&gt;
        down(s);                   #1&lt;br /&gt;
        recursoCompartido = valor; #2&lt;br /&gt;
        up(s);                     #3&lt;br /&gt;
    }&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Como vemos, los monitores se implementan con semáforos, son una abstracción de los mismos.&lt;br /&gt;
&lt;br /&gt;
== Ejemplo del funcionamiento de una clase monitor ==&lt;br /&gt;
&lt;br /&gt;
Dado un cierto recurso compartido protegido por una clase monitor denominada ''RecursoCompartido'' con los siguientes métodos:&lt;br /&gt;
&lt;br /&gt;
* '''get''', permite obtener el valor del recurso compartido, devuelve un entero.&lt;br /&gt;
* '''set''', permite establecer el valor del recurso compartido.&lt;br /&gt;
&lt;br /&gt;
Suponga ya creada un objeto RecursoCompartido para dos hilos h1 y h2:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang=&amp;quot;java&amp;quot;&amp;gt;&lt;br /&gt;
RecursoCompartido r = new RecursoCompartido();&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Dichos hilos tienen el siguiente código:&lt;br /&gt;
&lt;br /&gt;
* Lector (h1):&lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang=&amp;quot;java&amp;quot;&amp;gt;&lt;br /&gt;
int valor;&lt;br /&gt;
for(int j=0; j&amp;lt;2; j++) {     #1&lt;br /&gt;
  valor=r.get();             #2&lt;br /&gt;
  print(valor);              #3&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/source&amp;gt;   &lt;br /&gt;
&lt;br /&gt;
* Escritor (h2):&lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang=&amp;quot;java&amp;quot;&amp;gt;&lt;br /&gt;
int i=0;&lt;br /&gt;
for(int j=0; j&amp;lt;2; j++) {     #1&lt;br /&gt;
  r.set(i);                  #2&lt;br /&gt;
  i++;                       #3&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Suponiendo turno rotatorio estricto con quantum de 4 unidades de tiempo y que el planificador da paso en primer lugar al hilo h1. El cronograma con la representación de la ejecución sería el siguiente:&lt;br /&gt;
&lt;br /&gt;
                        &amp;lt; = lanzamiento del proceso&lt;br /&gt;
                        &amp;gt; = finalización del proceso                                                                       &lt;br /&gt;
                        x = indica que el proceso está asignado al procesador en ese momento.&lt;br /&gt;
                        B = el proceso pasa a estado bloqueado&lt;br /&gt;
                        P = el proceso pasa a estado preparado&lt;br /&gt;
 &lt;br /&gt;
                               Asignación del recurso procesador&lt;br /&gt;
 &lt;br /&gt;
         | 1 |2.1|2.2|2.3|   |   |2.4|2.5| 3 | 1 |   |   |   |   |2.1|2.2|2.3|2.4|   |   |   |   |2.5| 3 | 1 |   |&lt;br /&gt;
     h1  &amp;lt;---|---|---|---P   |   |---|---|---|---P   |   |   |   |---|---|---|---|   |   |   |   |---|---|---&amp;gt;   |&lt;br /&gt;
         |   |   |   |   | 1 |2.1|   |   |   |   |2.2|2.3| 3 | 1 |   |   |   |   |2.1|2.2|2.3| 3 |   |   |   | 1 |&lt;br /&gt;
     h2  |   |   |   |   &amp;lt;---|---B   P   |   |   |---|---|---|---P   |   |   |   |---|---|---|---|   |   |   |---&amp;gt;&lt;br /&gt;
         ----|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|&lt;br /&gt;
         0   1   2   3   4   5   6   7   8   9   10  11  12  13 14  15  16  17  18  19  20  21  22  23  24  25  26&lt;br /&gt;
  &lt;br /&gt;
          Nota: Los números de la parte superior a los guiones, indican el número de instrucción que &lt;br /&gt;
                se está ejecutando en dicho momento. En el caso de los 2.1, 2.2 y sucesivos se &lt;br /&gt;
                refieren al número de instrucción qué internamente se ejecutan en el get() y set() &lt;br /&gt;
                del monitor (Ver la implementación de la clase monitor de RecursoCompartido vista en clase).&lt;br /&gt;
&lt;br /&gt;
[[Usuario:Migoligon|Migoligon]] 16:51 4 dic 2011 (UTC)Porqué h1 no tiene la P de preparado en el 2.4 ni h2 en el último 3, y porqué h2 no se bloquea en el 2º down??&lt;br /&gt;
 &lt;br /&gt;
En la página de [https://1984.lsi.us.es/wiki-ssoo/index.php/Discusi%C3%B3n:Monitores discusión] hay un ejemplo en java.&lt;br /&gt;
&lt;br /&gt;
== Fuentes ==&lt;br /&gt;
&amp;lt;references/&amp;gt;&lt;/div&gt;</summary>
		<author><name>Danescsan</name></author>	</entry>

	<entry>
		<id>https://1984.lsi.us.es/wiki-ssoo/index.php?title=Concurrencia_de_procesos&amp;diff=2040</id>
		<title>Concurrencia de procesos</title>
		<link rel="alternate" type="text/html" href="https://1984.lsi.us.es/wiki-ssoo/index.php?title=Concurrencia_de_procesos&amp;diff=2040"/>
				<updated>2011-12-03T19:59:56Z</updated>
		
		<summary type="html">&lt;p&gt;Danescsan: /* Programación concurrente */ Corrección ortográfica&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;La concurrencia de procesos se refiere a las situaciones en las que dos o más procesos puedan coincidir en el acceso a un recurso compartido o, dicho de otra forma, que requieran coordinarse en su ejecución. Para evitar dicha coincidencia, el sistema operativo ofrece mecanismos de arbitraje que permiten coordinar la ejecución de los procesos.&lt;br /&gt;
&lt;br /&gt;
Un ejemplo de un problema de concurrencia sería el siguiente: Dados dos procesos A y B, suponiendo que ambos se ejecutan indefinidamente en el tiempo, el proceso A debe recibir tiempo de ejecución antes que B, tras esto, el proceso B debe recibir su oportunidad de ejecución, dando paso de nuevo al proceso A y así sucesivamente.&lt;br /&gt;
&lt;br /&gt;
 proceso A |--  --  --&lt;br /&gt;
           |&lt;br /&gt;
 proceso B |  --  --  --&lt;br /&gt;
           |_____________&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Recuerde que el planificador de procesos, al desconocer la naturaleza de los procesos y sus objetivos, no dispone de información suficiente como para garantizar la secuencia de ejecución descrita en el ejemplo anterior. Por tanto, suponiendo que ambos procesos se encuentran en estado preparado, podría seleccionar al proceso B para pasar a estado activo antes de seleccionar al proceso A, situación que no es deseada.&lt;br /&gt;
&lt;br /&gt;
Recuerde que el planificador de procesos, como hemos visto en capítulos anteriores, emplea [[Criterios de planificación|criterios de planificación]] que no tienen en consideración el objetivo de los procesos. Podemos decir que el planificador de procesos '''desconoce''' cuál es el propósito de los procesos, únicamente puede observar su comportamiento, es decir, si presentan un comportamiento más o menos interactivo.&lt;br /&gt;
&lt;br /&gt;
Por tanto, el programador, a la hora de modelar los procesos, debe emplear mecanismos de arbitraje que ofrece el sistema operativo y que permiten resolver el problema de concurrencia que se plantee.&lt;br /&gt;
&lt;br /&gt;
= Formas de interacción entre procesos =&lt;br /&gt;
&lt;br /&gt;
Hay dos formas básicas de interacción entre los procesos:&lt;br /&gt;
&lt;br /&gt;
* '''Relaciones de competencia''': Dados dos procesos A y B, ambos procesos tienen objetivos diferentes y compiten por los recursos para conseguirlos. Por ejemplo, dos procesos desean modificar el contenido de un mismo fichero, pero no deben hacerlo de manera simultánea o quedará en un estado incoherente.&lt;br /&gt;
&lt;br /&gt;
* '''Relaciones de cooperación''': Dados dos procesos A y B, ambos con un mismo objetivo, ''se ponen de acuerdo'' a la hora de emplear los recursos existentes para alcanzarlos. Por ejemplo, si el proceso A produce un objeto que es consumido por el proceso B, hasta que el proceso A no produzca, el proceso B no debe consumir y viceversa.&lt;br /&gt;
&lt;br /&gt;
= Mecanismos de arbitraje =&lt;br /&gt;
&lt;br /&gt;
Los mecanismos de arbitraje que ofrece el sistema operativo son básicamente dos:&lt;br /&gt;
&lt;br /&gt;
* Mecanismos de '''sincronización''': el sistema operativo ofrece mecanismos que permiten a los procesos coordinar su ejecución para conseguir el objetivo sin que sucedan situaciones no deseadas, como por ejemplo que dos o más procesos coincidan simultáneamente en el acceso a un cierto recurso que no se puede compartir.&lt;br /&gt;
&lt;br /&gt;
* Mecanismos de '''mensajería''': el sistema operativo ofrece mecanismos de comunicación entre procesos mediante mensajes. El intercambio de mensajes entre procesos permite coordinarlos.&lt;br /&gt;
&lt;br /&gt;
= Programación concurrente = &lt;br /&gt;
&lt;br /&gt;
El término programación concurrente se emplea con frecuencia para referirse a un conjunto de programas que funcionan en cooperación.&lt;br /&gt;
&lt;br /&gt;
Hay tres formas de interacción entre procesos cooperativos:&lt;br /&gt;
&lt;br /&gt;
*Concurrencia: Hay un recurso común, si varios procesos modificaran  la misma información a la vez , cada uno podría destruir parte del trabajo de los demás. Si lo hacen uno tras otro, en serie, se obtendrá el resultado correcto.&lt;br /&gt;
&lt;br /&gt;
*Sincronización: El Sistema Operativo se encarga de enviarle señales a los procesos para coordinar su evolución y conseguir que progrese armónicamente.&lt;br /&gt;
&lt;br /&gt;
*Comunicación:  El S.O. transmite mensajes entre los procesos, que se usan para intercambiar, enviar o recibir información.&lt;br /&gt;
&lt;br /&gt;
Se le llama programación concurrente ya que la concurrencia fue la primera forma de iterar recursos entre procesos cooperativos.&lt;br /&gt;
&lt;br /&gt;
= Sección crítica =&lt;br /&gt;
&lt;br /&gt;
La sección crítica es aquella zona donde un proceso está usando un recurso compartido.&lt;br /&gt;
&lt;br /&gt;
Para evitar interferencias en el uso de un recurso y con ello se produzcan resultados no deseados, se debe garantizar la exclusión mutua de procesos.&lt;br /&gt;
&lt;br /&gt;
Ésta exclusión de procesos, se debe realizar de forma coordinada y eficiente, para ello se requiere:&lt;br /&gt;
&lt;br /&gt;
*No más de un proceso por sección crítica y recurso compartido.&lt;br /&gt;
&lt;br /&gt;
*El mismo proceso no puede usar el mismo recurso compartido indefinidamente.&lt;br /&gt;
&lt;br /&gt;
*Todo proceso debe entrar antes o después a usar el recurso.&lt;br /&gt;
&lt;br /&gt;
*Si el recurso está sin uso, cualquiera que lo requiera dispondrá de él inmediatamente.&lt;br /&gt;
&lt;br /&gt;
*Si hay varios esperando usar el recurso y éste se libera, uno de los que estaba esperando lo usará durante un tiempo determinado.&lt;br /&gt;
&lt;br /&gt;
Para llevar ésto a cabo se necesita un protocolo que indique cuando el recurso está libre y cuando está siendo ocupado.&lt;br /&gt;
&lt;br /&gt;
= Tipos de mecanismos de sincronización =&lt;br /&gt;
&lt;br /&gt;
Los mecanismos de sincronización los podemos catalogar en dos categorías:&lt;br /&gt;
&lt;br /&gt;
*[[Mecanismos de sincronización#Optimista|Optimistas]]: Este mecanismo considera que la frecuencia de acceso a un cierto recurso compartido es ''baja''. Este tipo tiene mas consumo de memoria, ya que tiene que copiar el recurso compartido y en caso de interferencia en el hilo tiene que volver a ejecutarlo y consume mas recursos.&lt;br /&gt;
&lt;br /&gt;
*[[Mecanismos de sincronización#Pesimista|Pesimistas]]: Este mecanismo permite coordinar la ejecución de dos o más procesos que acceden al recurso compartido con una frecuencia ''alta''.&lt;br /&gt;
&lt;br /&gt;
Dependerá del criterio del programador el tipo de mecanismo que utilice ya que puede que no elija el tipo correcto. Por ejemplo, puede que la frecuencia de acceso a un cierto recurso sea alta y el programador le asigna un mecanismo optimista, esto provocaría no obtener el resultado esperado.&lt;/div&gt;</summary>
		<author><name>Danescsan</name></author>	</entry>

	</feed>