prefacio El objetivo principal de este prlogo es explicar la especificacin "versin preliminar", que aparece en la portada de estas notas de la conferencia.

Han sido preparados bajo presin considerable de dientes, las circunstancias en las que no pude tener mi uso del idioma Ingls corregido por una circunstancia nativas, en las que no pude primeros en probar diferentes mtodos de presentacin. As como estn, espero que les sirvan a sus dos objetivos principales: dar a mis alumnos una gua en cuanto a lo que estoy diciendo y dar a mis amigos y familiares una idea de lo que estoy haciendo. El destino futuro de este manuscrito, que puede llegar a ser una monografa in statu nascendi, depender en gran medida sus reacciones ante ella. Tengo una gran deuda, por adelantado, a cualquier lector que sea tan amable como para tomarse la molestia de dar sus comentarios, ya sea en forma de sugerencias como la presentacin o el propio material puede ser mejorado, o en la forma de una apreciacin. A partir de los comentarios de este ltimo voy a tratar de tener una idea de si vale la pena, mientras que para perseguir este esfuerzo alguno y de preparar un ataque publicacin y agradable a un pblico ms amplio. E.W.Dijkstra. 0. Introduccin. Estas conferencias estn destinadas a todos aquellos que esperan que en sus futuras actividades se convertirn en serio en los problemas que se plantean tanto en el diseo o en las aplicaciones ms avanzadas de los equipos de procesamiento digital de la informacin, sino que se pretende adems para todos aquellos que estn interesados slo . Las aplicaciones que tenemos en mente son aquellos en los que la actividad de un ordenador debe incluir la reaccin adecuado a una variedad posiblemente gran de mensajes que pueden ser enviados a l en momentos impredecibles, una situacin que se produce en el control del proceso, control de trfico, control de existencias , banca aplicaciones, automatizacin del flujo de informacin en grandes organizaciones, servicio informtico centralizado y, por ltimo, todos los sistemas de informacin en el que un nmero de ordenadores estn acoplados uno a otro. El deseo de aplicar la informtica en la forma esbozada anteriormente tiene a menudo una fuerte motivacin econmica, pero en estas conferencias la no poco importante cuestin de la eficiencia no se destac demasiado. Vamos a ocuparnos mucho ms con los problemas lgicos que ocasionan, por ejemplo, cuando no se conocen relaciones de velocidad, las posibilidades de comunicacin restringidos, etc Tenemos la intencin de hacerlo con el fin de crear una visin ms clara de empate origen de las dificultades que se encuentran y en la naturaleza de nuestras soluciones. Para decidir si en determinadas circunstancias la aplicacin de nuestras tcnicas es econmicamente atractivo o no entra en el mbito de estas conferencias. Lamento que no puedo ofrecer una teora completamente elaborada, con frmulas letra griega, por as decirlo. Lo nico que puedo hacer en las actuales

circunstancias es ofrecer una variedad de problemas, junto con las soluciones. Y en la discusin de estos, solo nos queda esperar para que el sistema tanto en l como nos sea posible, para saber qu conceptos son relevantes, a medida que avanzamos. Que todo el que me sigue por esta carretera disfrutar de la fascinacin de estos problemas interesantes, tanto como yo! 1. Sobre la naturaleza de los procesos secuenciales. Nuestro problema es el campo propio la cooperacin entre dos o ms procesos secuenciales. Antes de que podamos entrar en este campo, sin embargo, tenemos que saber con toda claridad lo que llamamos "un proceso secuencial". A esta pregunta preliminar de la presente seccin est dedicada. Me gustara empezar mi elucidacin de la comparacin de dos mquinas para hacer el trabajo mismo ejemplo, el de una mquina no secuencial, el otro secuencial. Supongamos que cada uno de cuatro cantidades, llamada a [1]", "a [2]", "a [3]" y "[4]", respectivamente, el valor es dado. Nuestra mquina tiene que procesar estos valores de tal manera que, como su reaccin, de "decir" nosotros, que de las cuatro cantidades tiene el valor ms grande. Por ejemplo en el caso: una [1] = 7, un [2] = 12, un [3] = 2, un [4] = 9 la respuesta que se produce es "a [2]" (o slo "2". dando el valor de ndice que apunta al elemento mximo). Tenga en cuenta que la respuesta deseada sera incompleta si se define el conjunto de valores fueron-en orden-"7, 12, 2, 12". pues entonces no hay ningn elemento singular ms grande y la respuesta "a [2]" habra sido tan bien (o tan mal) como "[4]". Esto se remedia mediante el supuesto adicional, que de los cuatro valores dados, no hay dos iguales. Observacin 1. Si la respuesta requerida habra sido el valor mximo que ocurre entre las dadas, la ltima restriccin habra sido superfluo, porque entonces la respuesta correspondiente al valor de ajuste "7, 12, 2, 12" habra sido "12". Observacin 2. Nuestro restriccin "De los cuatro valores que no hay dos iguales" es todava algo vagamente formulado, lejos, qu entendemos por "iguales"? En los procesos a ser construido pares de valores se comparan entre s y lo que realmente se quiere decir es, que cada dos valores ser lo suficientemente diferente, por lo que el comparador inequvocamente decidir, cul de los dos es el ms grande. En otras palabras, la diferencia entre cualquiera de los dos debe ser grande en comparacin con "el poder de resolucin" de nuestros comparadores. En primer lugar, deber construir nuestra mquina no secuencial. Cuando asumimos nuestros valores dados a ser representado por las corrientes, podemos imaginar un comparador que consiste en un conmutador de dos vas, la posicin de que est esquemticamente controlada por las corrientes en las bobinas de los electroimanes como en la figura 1 y la figura 2.

Fig. 1 x<y

Fig.2 y<x

Cuando y actual es mayor que x corriente, el electroimn izquierda tira ms duro que el de la derecha y el interruptor cambia a la izquierda (Fig.l) y la entrada A est conectada a la salida B, y si x actual es el ms grande, por as obtener la situacin (Fig. 2) cuando la entrada A est conectado a la salida C. En los diagramas que se omiten las bobinas y representar un comparador con una caja pequea

slo representa en la parte superior de la entrada y en el lado inferior de las dos salidas. Las corrientes que se llevaron a travs de las bobinas se identifican en la pregunta escrita dentro de la caja y es la convencin de que la entrada se conecta a la salida del lado derecho cuando la respuesta a la pregunta es "S", a la izquierda salida cuando la respuesta es "No".

Fig. 3 Ahora podemos construir nuestra mquina como se indica en la figura 3. Al lado de la salida hemos elaborado cuatro lmparas indicadoras, una de las cuales se iluminan para indicar la respuesta. En la figura 4 se indican la posicin de los conmutadores cuando el valor de ajuste "7, 12, 2, 9" se aplica a ella. En los cuadros de las posiciones de los interruptores se ha indicado, los cables no conectados a la entrada se dibujan borrados.

fig. 4 Llamamos la atencin del lector sobre el hecho de que ahora slo las posiciones de los tres interruptores que conectan la salida 2 a la entrada, la materia, el lector es invitado a convencerse de que la posicin de los otros tres interruptores es de hecho irrelevante. Tambin es bueno dar una atencin momento para ver lo que ocurre en momentos en que nuestra mquina de la figura 3 se alimenta con cuatro "corrientes de valor". Obviamente, no se puede esperar para dar la respuesta correcta antes de las cuatro corrientes de valor se va a travs de las bobinas. Pero ni siquiera se puede esperar de ella para indicar la respuesta correcta tan pronto como las corrientes se aplican, para los interruptores deben ponerse en su posicin correcta, y esto puede llevar algn tiempo. En otras palabras: tan pronto como las corrientes se aplican (simultneamente o una despus de la otra) que debe esperar un periodo de tiempo caracterstico para la mquina y despus de que la respuesta correcta se muestra en el lado de salida. Lo que sucede en este tiempo de espera es irrelevante, siempre que sea lo suficientemente largo para que todos los interruptores para encontrar su posicin final. Pueden empezar cambiando al mismo tiempo, el orden exacto en el que alcancen su posicin final es inmaterial y, por lo tanto, no vamos a prestar atencin a lo ms. Desde el punto de vista lgico el tiempo de conmutacin puede ser considerada como un marcador en el eje de tiempo: antes de que los datos de entrada tienen que ser suministrados, despus de que la respuesta se encuentra disponible. En el uso de nuestra mquina el progreso del tiempo slo se refleja en lo obvio "antes - despus" de relacin, que nos dice que no podemos esperar una respuesta antes de la pregunta ha sido debidamente puesto. Esta relacin secuencia es tan evidente (y fundamental) que no puede ser considerada como una propiedad caracterstica de nuestra mquina. Y nuestra mquina se denomina por tanto un "no secuencial de la mquina", para distinguirla de la clase de equipoo procesos que pueden ser realizados por el mismo-que se describir ahora. Hasta ahora hemos interpretado el diagrama de la figura 3 que el cuadro (esquema) de una mquina que se construir en el espacio. Pero podemos interpretar este mismo diagrama de una manera muy diferente si nos ponemos en la mente del electrn que entra a la entrada superior y preguntndose a dnde ir. En primer lugar, se encuentra frente a la cuestin de si "a [l] <a [2]" sostiene. Despus de haber encontrado la respuesta a esta pregunta, se puede proceder. Dependiendo de la respuesta anterior, entrar una de las dos cajas "a [1] <a [3]" o "[2] <a [3]", es decir, slo sabr qu investigar siguiente, despus de la primera

pregunta ha sido contestada. Despus de haber encontrado la respuesta a la pregunta seleccionada a partir de la segunda lnea, se sabr qu pregunta hacer desde la tercera lnea y haber encontrado esta ltima respuesta ahora sabremos que la bombilla debe comenzar a brillar. En lugar de considerar el diagrama de la figura 3 como la de una mquina, las partes de las cuales se extienden en el espacio, lo hemos considerado como reglas de comportamiento, para ser seguido en el tiempo. Con respecto a nuestra anterior interpretacin dos diferencias son muy significativas. En la primera interpretacin a los seis comparadores comenz a trabajar al mismo tiempo, aunque finalmente slo tres posiciones interruptor de la materia. En la segunda interpretacin slo tres comparaciones se evaluaron en realidad-el electrn preguntando s mismo hace tres preguntas-, pero el precio de esta ganancia es que tienen que llevarse a cabo el uno despus del otro, como el resultado de la anterior decide qu preguntar siguiente . En la interpretacin segundos tres preguntas tienen que pedir en secuencia, la una despus de la otra. La existencia de dicha relacin de orden es la caracterstica distintiva de la segunda interpretacin que en contraste con el primero se denomina por tanto "un proceso secuencial". Nos gustara hacer dos observaciones. Observacin 3. En realidad, las tres comparaciones cada uno tomar una cantidad finita de tiempo (tiempo de cambio "," tiempo de decisin "o, para usar la jerga," plazo de ejecucin ") y como resultado, el tiempo total ser por lo menos igual a la suma de estos tres tiempos de ejecucin. Destacamos una vez ms, que para muchas investigaciones estas ejecuciones pueden ser consideradas como marcadores ordenados en un eje de tiempo sin escamas y que es slo la ordenacin relativa de que los asuntos de este punto (lgico) de vista. Observacin 4. Como una lnea pequea, observamos que las dos interpretaciones (los llaman "comparaciones simultneas" y "comparaciones secuenciales") son extremos solamente. Hay una manera de, de nuevo, slo de realizar tres comparaciones, en el que dos de ellos se puede hacer de forma independiente el uno del otro, es decir, simultneamente, la tercera, sin embargo, slo se puede hacer, despus de los otros dos se ha completado. Puede representarse con la ayuda de una caja en la que dos preguntas se formulan y que, como resultado, tiene cuatro posibles salidas, como en la figura 5.

Fig. 5 El tiempo total ser por lo menos la suma de los tiempos de ejecucin de comparacin. El proceso es de la primera clase en el sentido de que las primeras dos comparaciones se pueden realizar simultneamente, es de naturaleza secuencial como la comparacin tercera slo se puede seleccionar a partir de la

segunda lnea cuando los dos primeros han tanto se ha completado. Volvemos a nuestra interpretacin puramente secuencial. Sabiendo que el diagrama es para interpretacin puramente secuencial podemos aprovechar esta circunstancia que la descripcin de las "reglas de conducta" ms compacto. La idea es que las dos cuestiones prejudiciales sobre la segunda lnea de slo uno de los cuales se pide en realidad son muy similares: las preguntas en la misma lnea que slo se diferencian en el valor de subndice del operando izquierdo de la comparacin. Y podemos preguntarnos: "Podemos mapear las preguntas en la misma lnea de la figura 3 en una sola pregunta?" Esto se puede hacer, pero que implica que la parte que vara a lo largo de una lnea, es decir el valor de subndice de la izquierda el operando debe ser considerada como un parmetro, la tarea de la cual es determinar cul de las preguntas asignadas en cada otra se entiende, cuando su turno para ser ejecutado ha llegado. Obviamente, el valor de este parmetro debe ser definido por la historia pasada del proceso. Tales parmetros, en la que se puede condensar la historia pasada para uso futuro se llaman variables. Para indicar que un nuevo valor se debe asignar a ello utilizamos el operador de asignacin denominada ": =" (lase: "se hace"), una especie de signo de igualdad dirigida que define el valor de la parte izquierda de las golondrinas de mar de el valor de la mano derecha. Esperamos que el prrafo anterior es suficiente para que el lector reconocer tambin en el diagrama de la figura 6 un conjunto de "reglas de conducta". Nuestra variable se llama i, si el lector se pregunta, por qu la primera cuestin, que es invariablemente "? A [l] <a [2]" no se escribe de esa manera, se le ruega a tener un poco de paciencia.

Fig. 6 Cuando hemos seguido las reglas de la figura 6 como se pretende desde la parte superior hasta la inferior, el valor final de i identificar el valor mximo, a saber. a [i]. La transicin del esquema de la figura 3 a la de la figura 6 es un cambio drstico, en los ltimos "reglas de conducta" slo puede ser interpretado de forma

secuencial. Y esto es debido a la introduccin de la variable i: tener slo una [1], a [2], a [3] y una [4] disponible como valores de comparacin, la pregunta "a [i] <a [ 2]? " no tiene significado, a menos que se conoce para el que el valor de i esta comparacin tiene que ser hecho. Observacin 5. Es un poco triste que la jerga del comercio llama a lo indicado por la variable ia, porque en matemticas normales, el concepto de una variable es un concepto totalmente atemporal. El tiempo no tiene nada que ver con la x en la relacin sin (2 * x) = 2 * sin (x) * cos (x); si esa variable siempre denota un valor, denota "cualquier valor". Cada vez, sin embargo, que una variable en un proceso secuencial se utiliza-tal como en i "a [i]" - denota un valor muy especfico, a saber. el ltimo valor asignado a la misma, y nada ms! Mientras no nuevo valor se asigna a una variable, denota un valor constante! Estoy, sin embargo, demasiado vacilante para acuar nuevos trminos: en primer lugar lo hara esta monografa pretencioso sin pretenderlo, en segundo lugar creo que la acuacin (fashionable!) de nuevos trminos a menudo se aade tanto a la confusin de una manera, ya que elimina la otro. Por lo tanto, se adhieren al trmino "variable". Observacin 6. Uno se puede preguntar, qu estamos haciendo en realidad, cuando se introduce una variable sin especificar, por ejemplo, un dominio para ello, es decir, un conjunto de valores que se garantiza a todos los futuros comprenden sus valores reales. No vamos a perseguir este ms por el momento. Ahora vamos a someter a nuestro plan para una transformacin que viene. En la figura 3 se ha "envuelto" las lneas, ahora vamos a terminar el esquema de la figura 6 en la otra direccin, una operacin para la que recogemos son invitados por la naturaleza repetitiva de la misma y que se puede realizar en el precio de una variable siguiente, "j", dicen.

Fig.7 El cambio es dramtica, por el hecho de que el problema original fue identificar el valor mximo entre cuatro valores dados ya no se refleja en la "topologa" de las reglas de conducta: en la figura 7 slo encontramos el nmero "4 "que se menciona una sola vez. Mediante la introduccin de una variable, digamos n, y la sustitucin de la "4" en la figura 7 por n tenemos de repente las reglas de comportamiento para identificar el mximo ocurre entre los n elementos a [1], a [2],

.... ..., A [n] y esto. prcticamente slo por el precio que antes de la aplicacin, debe ser la variable n le d su justo valor Llam al cambio a un dramtico, porque ahora no slo hemos dado reglas de conducta que deben ser interpretados de forma secuencial, esto fue ya el caso de la figura 6, pero hemos ideado un mecanismo nico para identificar el valor mximo entre cualquier nmero de dado elementos, mientras que nuestro original no secuencial mquina slo podra construirse para un nmero previamente bien definido de los elementos. Hemos mapeado nuestras comparaciones en el tiempo en vez de en el espacio, y si queremos comparar los dos mtodos, es como si la mquina secuencial "se extiende" en trminos de la figura 3 segn sea necesario. Es nuestra ltima transicin que muestra los procesos secuenciales en todo su esplendor. El trmino tcnico para lo que hemos denominado "reglas de conducta" es un algoritmo o programa. (No se acostumbra a llamarlo "un programa secuencial", aunque este nombre sera totalmente correcto.) Equipo capaz de seguir esas reglas ", para ejecutar dicho programa" se llama "un ordenador de propsito general secuencial" o "equipo" para corto, lo que ocurre durante una ejecucin de un programa que se llama "un proceso secuencial". Existe una tcnica comnmente aceptada de escribir algoritmos sin la necesidad de tales imgenes como hemos utilizado, a saber. ALGOL 60 ("Algol" es la abreviatura de lenguaje algortmico). Para una discusin detallada de ALGOL 60, debo remitir al lector a la bibliografa existente. Vamos a utilizarlo en el futuro, siempre que sea conveniente para nuestros propsitos. En aras de la ilustracin, describiremos el algoritmo de la figura 7 (pero para n en lugar de "4") por una secuencia de estados Algol: i:=1; j:=1; back: if n then begin j:=j+1; if a[i] < a[j] then i:=j; goto back end. Las dos primeras declaraciones: "i: l =; j: = 1" son, espero, explica por s mismo. Luego viene "de nuevo:", una etiqueta de llamada, que se utiliza para identificar el lugar en el programa. Luego viene "si j n entonces", una clusula condicional llamada. Si la condicin expresada por llegare a la conclusin, la siguiente instruccin se llevar a cabo, de lo contrario, se omitir. (Otro ejemplo de ello se pueden encontrar dos lneas inferiores.) Cuando la amplitud del programa que puede tener que ser omitidos se presenta principalmente como una secuencia de ms de una instruccin, entonces se pone a los soportes de los estados llamados "begin" y "fin" en torno a esta secuencia, convirtindola as en una sola declaracin en cuanto a su entorno se refiere. (Esto es totalmente anlogo al efecto de los parntesis en frmulas algebraicas, tales como "a * (b + c)" donde el par parntesis indica que toda la expresin contenida en l es que se tomar como factor.) La ltima instruccin "goto back "significa que el proceso debe continuar en el punto

marcado por lo tanto, que hace exactamente lo mismo por nosotros como el lder de lnea ascendente de la figura 7. 2. Vagamente conectados Procesos. El objeto de esta monografa es la cooperacin entre dbilmente conectados procesos secuenciales y esta seccin se dedicar a un debate a fondo sobre un problema sencillo, pero representativo, a fin de dar al lector una idea de los problemas en esta rea. En la seccin anterior se ha descrito la naturaleza de un proceso secuencial nico, realizando su secuencia de acciones de forma autnoma, es decir, independiente de su entorno, tan pronto como se ha iniciado. Cuando dos o ms de tales procesos tienen que cooperar unos con otros, deben ser conectados, es decir, deben ser capaces de comunicarse entre s con el fin de intercambiar informacin. Como veremos a continuacin, las propiedades de estos medios de intercomunicacin juegan un papel vital. Adems, hemos estipulado que los procesos deben ser de manera floja; por esto queremos decir que, aparte de los momentos (raro) de intercomunicacin explcita, los procesos individuales mismos deben ser considerados como totalmente independientes uno de otro. En particular, no permitir ninguna suposicin acerca de las velocidades relativas de los diferentes procesos. (. Tal suposicin, digamos "procesos orientados a la misma velocidad de reloj" - podra ser considerada como la intercomunicacin implcita) Esta independencia de relaciones de velocidades est en estricta conformidad con nuestra apreciacin del proceso secuencial nico: su caracterstica esencial slo es que su elemental etapas se realizan en secuencia. Si prefiere observar la actuacin con un cronmetro en la mano, podemos hacerlo, pero el proceso en s sigue siendo muy afectados por esta observacin. Advierto al lector que mi negativa constante a hacer ninguna suposicin acerca de las relaciones de velocidad se parecer a primera vista como una mala pasada a hacer las cosas ms difciles de lo que ya son. Creo, sin embargo, plenamente justificado en mi negativa. En primer lugar, puede que tengamos que hacer frente a situaciones en las que, de hecho, muy poco se sabe acerca de las velocidades. Por ejemplo, parte del sistema puede ser una estacin de entrada de accionamiento manual, otra parte del sistema puede ser tal, que se pueda parar externamente para cualquier perodo de tiempo, lo que reduce su velocidad temporalmente a cero. En segundo lugar-y esto es mucho ms importante-cuando pensamos que podemos confiar en ciertas relaciones de velocidad, descubriremos que hemos sido "libra tonto y penique sabio". Es cierto que algunos mecanismos pueden ser ms simples en el supuesto de restricciones con reduccin de velocidad. La verificacin, sin embargo, que esta hiptesis se justifica siempre, es en general muy difcil y la tarea a realizar, de una manera fiable, una estructura de buen comportamiento de muchos componentes interrelacionados se ve seriamente agravada cuando estas "interferencias analgicas" tienen que ser tener en cuenta tambin. (Para una cosa: har el trabajo adecuado un equilibrio bastante inestable,

sensible a cualquier cambio en las diferentes velocidades, como pueden surgir fcilmente por sustitucin de un componente por otro-por ejemplo, la sustitucin de una impresora de lneas por un modelo ms rpido-o reprogramacin de una cierta porcin.) 2,1. Un ejemplo sencillo. Despus de estas palabras de introduccin voy a discutir el problema en primer lugar. Se consideran dos procesos secuenciales, "Proceso 1" y "proceso 2", que para nuestros propsitos puede ser considerado como cclico. En cada ciclo de una llamada "seccin crtica" se produce, crtica en el sentido de que los procesos tienen que ser construidos de tal manera, que en cualquier momento al menos uno de los dos est comprometido en su seccin crtica. Con el fin de efectuar esta exclusin mutua de los dos procesos tienen acceso a un nmero de variables comunes. Postulamos, que inspeccionar el valor actual de una variable comn y asignar un nuevo valor a una variable comn deben ser considerados como indivisibles, que no interfieren acciones. Es decir cuando los dos procesos asignar un nuevo valor a la variable comn mismo "simultneamente", entonces las tareas han de ser considerados como hecho la una despus de la otra, el valor final de la variable ser uno de los dos valores asignados, pero una nunca "mezcla" de los dos. Del mismo modo, cuando un proceso inspecciona el valor de una variable comn "simultneamente" con la asignacin a ella por la otra, entonces el proceso primero se encuentra el antiguo o el nuevo valor, pero no una mezcla. Para nuestros propsitos ALGOL 60 tal como est no es adecuado, como ALGOL 60 ha sido diseado para describir un proceso secuencial nico. Por ello, proponemos la siguiente extensin que nos permita describir paralelismo de ejecucin. Cuando una secuencia de declaraciones-separados por punto y coma, como de costumbre en ALGOL 60 - est rodeado por el par comunicado soporte especial "parbegin" y "parend", esto es, debe interpretarse en ejecucin en paralelo de los estados constituyentes. La totalidad de la construccin-llammoslo "un compuesto paralelo" - puede considerarse como una declaracin. Iniciacin de un compuesto paralela implica la iniciacin simultnea de todos sus estados constituyentes, su ejecucin se completa despus de la terminacin de la ejecucin de todos sus estados constituyentes. Por ejemplo: comenzar S1; parbegin S2; S3; S4; parend; S5 final (En la que S1, S2, S3. S4 y S5 se utilizan para indicar estados) significa que despus de la terminacin de S1, los estados S2. S3 y S4 se pueden ejecutar en paralelo, y slo cuando estn acabados, a continuacin, la ejecucin de instruccin 55 se iniciar. Con estos convenios, podemos describir nuestra primera solucin:

begin integer turn; turn:= 1; parbegin process 1: begin Ll: if turn = 2 then goto Ll; critical section 1; turn:= 2; remainder of cycle 1; goto L1 end; process 2: begin L2: if turn = 1 then goto L2; critical section 2; turn:= 1; remainder of cycle 2; goto L2 end parend end. (Nota para los inexpertos ALGOL 60 lector. Despus de "comenzar" en la primera lnea se encuentra la denominada declaracin "giro entero", con lo que se pegue a la regla de ALGOL 60 que el texto del programa no se permite hacer referencia a las variables sin haber introducido ellos con la ayuda de una declaracin. Como esta declaracin se produce despus de que el "begin" de la pareja declaracin soporte ms exterior significa que durante toda la duracin del programa de una variable que se ha introducido slo tomar valores enteros y en que el programa texto puede hacer referencia por medio del nombre de "giro".) Los dos procesos se comunican entre s a travs del entero comn "giro", cuyo valor indica cual de los dos procesos es la primera para llevar a cabo (o ms bien: a fin) en su seccin crtica. Desde el programa, est claro que despus de la primera asignacin, los nicos valores posibles de la variable "turn" son 1 y 2. La condicin para que el proceso 2 para entrar en su seccin crtica, es que se encuentre en algn momento "giro 1", es decir, "vuelta = 2". Pero la nica forma en la que la variable "giro" puede obtener este valor es mediante la cesin "a su vez: = 2" en el proceso 1. Como proceso 1 realiza esta asignacin slo en la terminacin de su seccin crtica, proceso 2 slo puede iniciar su seccin crtica despus de la finalizacin de la seccin crtica 1. Y 1 seccin crtica podra de hecho ser iniciado, porque la condicin inicial "de vuelta = 1" implcita "giro 2", de modo que el ciclo de espera potencial, L1 marcado, fue inicialmente inactivo. Despus de la cesin "a su vez: = 2", los papeles de los dos procesos estn intercambiados. (Nota: Se supone que las nicas referencias a la variable "turno" son los que se muestran de forma explcita en el programa.) Nuestra solucin, aunque correcta, es, sin embargo, innecesariamente restrictivo: despus de la finalizacin de la seccin crtica 1, el valor de la variable "giro" se convierte en "2", y debe ser = 1 de nuevo, antes de la prxima entrada en una seccin crtica . Como resultado, la sucesin slo admisible de secciones crticas es la estrictamente alternados uno "1,2,1,2,1,2,1, .....", en otras palabras, los dos procesos estn sincronizados. Con el fin de subrayar explcitamente que este no es el tipo de solucin que deseaba, se impone la condicin adicional "Si uno de los

procesos se detiene bien fuera de su seccin crtica, esto no est permitido para conducir a potencial de bloqueo del otro proceso." . Esto hace que nuestra solucin anterior inaceptable y tenemos que esperar a otro. Nuestro segundo esfuerzo trabaja con dos nmeros enteros "C1" y "C2", donde c = 0/1 respectivamente indicar que el proceso correspondiente en su interior / exterior de seccin crtica, respectivamente. Podemos tratar de la siguiente construccin: begin integer c1, c2; c1:= 1; c2:= 1; parbegin process1: begin L1: if c2 = 0 then goto L1; c1: = 0; critical section 1; c1:= 1; remainder of cycle 1; goto L1 end; process2: begin L2: if c1 = 0 then goto L2; c2: = 0; critical section 2; c2:= 1; remainder of cycle 2; goto L2 end parend end. Las asignaciones primera configurar tanto de c = 1, de acuerdo con el hecho de que los procesos se inician fuera de sus secciones crticas. Durante toda la ejecucin de la seccin crtica 1 la relacin "c1 = 0" y sostiene la primera lnea de proceso 2 es efectivamente un tiempo de espera "esperar siempre como proceso 1 es en su seccin crtica.". La solucin de prueba da de hecho una cierta proteccin contra la simultaneidad de ejecucin seccin crtica, sino que es, por desgracia, demasiado simple, porque lo que est mal. Vamos proceso primero 1 encontrar que c2 = 1; dejar que el proceso 2 inspeccionar c1 inmediatamente despus, entonces ser (todava) encontrar c1 = 1. Ambos procesos, habiendo encontrado que el otro no se encuentra en su seccin crtica, concluir que puedan entrar en su propia seccin con seguridad! Hemos sido demasiado optimistas, tenemos que jugar un juego ms seguro. Vamos a invertir, al comienzo de los procesos paralelos, la inspeccin de la "c" de la otra y la configuracin de la propia "c". A continuacin, obtener la construccin:

begin integer c1, c2; c1:= 1; c2:= 1; parbegin process 1: begin A1: c1:= 0; L1: if c2 = 0 then goto Ll; critical section 1; c1:= 1; remainder of cycle 1; goto A1 end; process 2: begin A2: c2:= 0; L2: if c1 = 0 then goto L2; critical section 2; c2:= 1; remainder of cycle 2; goto A2 end parend end . Vale la pena para verificar que esta solucin es al menos completamente seguro. Vamos a centrar nuestra atencin en el momento en que se encuentra el proceso 1 c2 = 1, por lo que decide entrar en su seccin crtica. En este momento podemos concluir 1) que la relacin "c1 = 0" ya tiene y seguir presionando hasta que un proceso ha finalizado la ejecucin de su seccin crtica, 2) que, como "c2 = 1" se mantiene, el proceso 2 est bien fuera de su seccin crtica, que no puede entrar siempre y cuando "c1 = 0" se mantiene, es decir, mientras un proceso todava est activado en su seccin crtica. As, la exclusin mutua es, en efecto garantizado. Pero esta solucin, por desgracia, tambin debe desestimarse: en su medidas de seguridad que ha sido demasiado drstico, ya que contiene el peligro de bloqueo de determinadas mutuas. Cuando despus de la cesin "c1: = 0", pero an antes de la inspeccin de c2 (tanto por el proceso 1) proceso 2 realiza la cesin "c2: = 0", entonces ambos procesos han llegado a L1 o L2 etiqueta, respectivamente, y ambas relaciones c1 "= 0 "y" c2 = 0 "que, con el resultado de que ambos procesos se espere unos sobre otros hasta la eternidad. Por lo tanto, esta solucin tambin debe ser rechazada. No estaba mal para configurar la propia "c" antes de inspeccionar la "c" de la otra, sino que fue un error meter a la propia c-ajuste y slo esperar. Esto es (un poco) remediarse en la siguiente construccin:

begin integer c1, c2; c1:= 1; c2:= 1; parbegin

process 1: begin L1: c1:= 0; if c2 = 0 then begin c1:= 1; goto L1 end; critical section 1; c1:= 1; remainder of cycle 1; goto L1 end; process 2: begin L2: c2:= 0; if c1 = 0 then begin c2:= 1; goto L2 end; critical section 2; c2:= 1; remainder of cycle 2; goto L2 end parend end . Esta construccin es tan seguro como el anterior y, cuando las asignaciones "c1: = 0" y "c2: = 0" se realizan "al mismo tiempo" no conducir necesariamente a infinitum mutuo bloqueo de anuncios, ya que ambos procesos se restablecer su propio "c" de nuevo a 1 antes de volver a los ritos de entrada, permitiendo as que el otro proceso para tomar la oportunidad. Pero nuestros principios nos obligan a rechazar tambin esta solucin, por la negativa a hacer ninguna suposicin acerca de la relacin de velocidades implica que tenemos que atender a todas las velocidades, y la ltima solucin admite las velocidades de ser tan ajustado cuidadosamente que los procesos de inspeccionar la calidad de otro "c" slo en aquellos periodos de tiempo que su valor es = 0. Para dejar en claro que rechazamos este tipo de soluciones que slo funcionan con un poco de suerte, declaramos nuestro siguiente requisito: "Si los dos procesos estn a punto de entrar en su seccin crtica, debe ser imposible de concebir para ellos esas velocidades finitas, que la decisin que uno de los dos es el primero en entrar en su seccin crtica se pospone hasta la eternidad. ". De paso, tenga en cuenta, que la solucin acaba de rechazar es la vida cotidiana muy aceptable. Por ejemplo, cuando dos personas estn hablando por telfono y de repente se desconecta, por lo general ambos tratan de restablecer la conexin. Ambos dial y si reciben la seal de "Number Engaged", se colg el auricular y, si no lo ha llamado, tratan de "algunos" segundos despus. Por supuesto, esto puede coincidir con el siguiente esfuerzo de la otra parte, pero por regla general se restablece la conexin con xito despus de muy pocos ensayos. En nuestras circunstancias mecnicas, sin embargo, no podemos aceptar este patrn de comportamiento: las partes podran muy bien ser idnticos! Toda una coleccin de soluciones de prueba han demostrado ser incorrecta y en algn momento las personas que haban jugado con el problema comenz a dudar de si podra ser resuelto en absoluto. Para el matemtico holands Th.J.Dekker el crdito es debido para la solucin correcta primero. Es, de hecho, una mezcla de nuestros esfuerzos anteriores: utiliza la "esclusa seguro" de nuestras ltimas

construcciones, junto con el nmero entero "giro" de la primera, pero slo para resolver la indeterminacin cuando ninguno de los dos sucede inmediatamente . El valor inicial de "giro" podra haber sido 2 tambin. begin integer c1, c2 turn; c1:= 1; c2:= 1; turn = 1; parbegin process 1: begin A1: c1:= 0; L1: if c2 = 0 then begin if turn = 1 then goto L1; c1:= 1; B1: if turn = 2 then goto B1; goto A1 end; critical section 1; turn:= 2; c1:= 1; remainder of cycle 1; goto A1 end; process 2: begin A2: c2:= 0; L2: if c1 = 0 then begin if turn = 2 then goto L2; c2:= 1; B2: if turn = 1 then goto B2; goto A2 end; critical section 2; turn:= 1; c2:= 1; remainder of cycle 2; goto A2 end parend end . Vamos ahora a demostrar la exactitud de esta solucin. Nuestra primera observacin es que cada proceso slo funciona por s solo "c". Como resultado de un proceso 1 inspecciona "c2" slo mientras "c1 = 0", slo entrar en su seccin crtica siempre que encuentra "c2 = 1"; para el proceso 2 observacin anloga puede ser hecho. En resumen, reconocemos la esclusa seguro de nuestras ltimas construcciones y la solucin est a salvo en el sentido de que los dos procesos no pueden estar en su seccin crtica al mismo tiempo. La segunda parte de la prueba tiene que demostrar que en caso de duda, la decisin de cul de los dos ser el primero en entrar no se puede posponer hasta la eternidad. Ahora debemos prestar atencin al nmero entero "turn": tomamos nota de que la asignacin de esta variable slo se produce al final-o, si lo desea: como parte de las secciones crticas y por lo tanto podemos considerar la variable "giro" como un constante durante este proceso de decisin. Supongamos que el "giro = 1". Entonces proceso 1 slo puede ciclo a travs de Ll, que es con "c1 = 0" y slo durante el tiempo en que

considera "c2 = 0". Pero si "vuelta = 1" entonces el proceso 2 puede slo ciclo va B2, pero este estado implica "c2 = 1", por lo que el proceso 1 no puede y est obligado a entrar en su seccin crtica. Para la "vuelta = 2", el razonamiento se aplica espejo. Como tercera y ltima parte de la prueba se observa que parar, por ejemplo, un proceso en el "resto del ciclo 1" no va a restringir el proceso 2: la relacin "c1 = 1" y luego llevar a cabo y procesar 2 puede entrar en su seccin crtica alegremente, bastante independiente del valor actual de "turno". Y esto completa la demostracin de la correccin de la solucin de Dekker. Aquellos lectores que no logran apreciar su ingenio, se ruega a darse cuenta de que para ellos he preparado el terreno por medio de un conjunto cuidadosamente seleccionado de construcciones rechazadas. 2,2. El problema generalizada exclusin mutua. El problema de la seccin 2,1 tiene una generalizacin natural: dado n procesos cclicos, cada uno con una seccin crtica, los podemos construir de tal manera, que en cualquier momento al menos uno de ellos se acopla en su seccin crtica? Asumimos el mismo medio de intercomunicacin disponibles, es decir, un conjunto de variables de acceso comn. Adems, nuestro so1ution tiene que satisfacer los mismos requisitos, que detener un proceso bien fuera de su seccin crtica puede de ninguna manera restringir la libertad de los dems, y que si hay ms de un proceso est a punto de entrar en su seccin crtica, debe ser imposible disear para ellos esas velocidades finitas, que la decisin de cul de ellos es el primero en entrar en su seccin crtica, puede ser pospuesto hasta la eternidad. Con el fin de ser capaz de describir la solucin en ALGOL 6O, necesitamos el concepto de la matriz. En la seccin 2.1 hemos tenido que introducir una "c" para cada uno de los dos procesos y as lo hicimos, al declarar

integer array c1, c2 .

En lugar de enumerar las cantidades, podemos declarar, bajo el supuesto de que "N" tiene una bien definida positiva de valor

integer array c[1 : N]

lo que significa, que en un accidente cerebrovascular hemos introducido enteros N, accesibles bajo los nombres

c[subscript],
donde el "subndice" puede tomar los valores 1, 2, ....... N. El prximo nuevo ALGOL 60 caracterstica que se utiliza es la denominada "clusula de" que vamos a utilizar en la forma siguiente:

for j:= 1 step 1 until N do statement S ,

y que nos permite expresar la repeticin de "S declaracin" bastante cmoda. En principio, la clusula implica que la "declaracin S" se ejecutar N veces, con "j" en la serie = 1, = 2, ......, = N. (Hemos aadido "en principio", por a travs de una instruccin goto como parte constituyente de S declaracin y llevando a cabo de la misma, la repeticin se puede terminar antes.)

Por ltimo tenemos el operador lgico que en esta monografa se denota por "y". Nos hemos reunido con la clusula condicional en la forma:

if condition then statement .

Ahora se reunir:

if condition 1 and condition 2 then statement S .

lo que significa que S declaracin slo se ejecutar si "estado 1" y "estado 2" estn satisfechos. (Una vez ms nos gustara hacer hincapi en que esta monografa no es un manual de programacin ALGOL 60: lo anterior-loose - explicacin de 6O ALGOL slo se han introducido para hacer esta monografa como autnomo es posible.) Con la notacin ayudas que acabamos de esbozar, podemos describir nuestra solucin de N fijado como sigue. La estructura general es:

begin integer array b, c[O : N]; integer turn; for turn:= 0 step 1 until N do begin b[turn]:= 1 end; turn:= 0; parbegin process 1: begin.....................end; process 2: begin.....................end; . . . . . . . process N: begin.....................end parend end . The first declaration introduces two arrays with N + 1 elements each, the next declaration introduces a single integer "turn". In the following for clause this variable "turn" is used to take on the successive values 1, 2, 3,......, N, so that the two arrays are initialized with all elements = 1. Then "turn" is set = 0 (i.e. none of the processes, numbered from 1 onwards, is privileged). After this the N processes are started simultaneously.

The N processes are all similar. The structure of the i-th process is as follows (1 i N) :
La primera declaracin introduce dos matrices con n + 1 elementos cada uno, la siguiente declaracin presenta un nico entero "turn". En la siguiente clusula de esta variable "giro" se utiliza para asumir los valores sucesivos 1, 2, 3, ......, n, de modo que las dos matrices se inicializan con todos los elementos = 1. A continuacin, "vuelta" est ajustado = 0 (es decir, ninguno de los procesos, numerados del 1 en adelante, tiene el privilegio). Despus de esto los N procesos se inician simultneamente. N Los procesos son similares. La estructura del proceso i-simo es el siguiente (1 i N):

process i: begin integer i; Ai: b[i]:= 0; Li: if turn i then begin c[i]:= 1; if b[turn] = 1 then turn:= i; goto Li end; c[i]:= 0; for j:= 1 step 1 until N do begin if j i and c[j] = 0 then goto Li end; critical section i turn:= 0; c[i]:= 1; b[i]:= 1; remainder of cycle i; goto Ai end .
Observacin. La descripcin de los procesos individuales N comienza con la declaracin de "entero j". De acuerdo a las reglas del ALGOL 60, esto significa que cada proceso entero presenta su propio y privado "j" (lo que se denomina "cantidad local"). Salimos de la prueba para el lector. Tiene que mostrar una vez ms: 1) que en cualquier momento al menos uno de los procesos se acopla en su seccin crtica 2) que la decisin de cual de los procesos es el primero en entrar en su seccin crtica no puede ser pospuesto hasta la eternidad 3) que la detencin de un proceso en su "el resto del ciclo" no tiene ningn efecto sobre las otras. De estas partes, la segunda es la ms difcil. (Sugerencia: en cuanto uno de los procesos ha llevado a cabo la cesin "a su vez: = i", sin nuevos procesos pueden decidir asignar su nmero a convertir antes de una seccin crtica se ha completado la mente que dos procesos pueden decidir "al mismo tiempo" a. asignar su valor i-dar vuelta!) (Observacin, que se puede saltar a la primera lectura.) El programa que

acabamos de describir inspecciona el valor de "b [a su vez]", donde tanto la matriz "b" y el entero "turn" estn en el almacn comn. Hemos dicho que la inspeccin de una sola variable es una accin indivisible e inspeccin "b [a su vez]" por lo tanto, slo puede significar: controlar el valor de "turno", y si esto pasa a ser = 5, bueno, entonces inspeccionar "b [5 ] ". O, en ALGOL ms explcito:

process i:= begin integer j, k; . . . . k:= turn; if b[k] = 1 then........ ,

lo que implica que en el momento en que "b [k]" es inspeccionado, "giro" slready puede tener un valor diferente de la corriente de "k". Sin las limitaciones establecidas en la comunicacin con el almacn comn, una posible interpretacin de "el valor de b [a su vez]" habra sido "el valor del elemento de la matriz b, como se indica por el valor actual del turno". En los as llamados uniprogramming -i.e. un nico proceso operativo seouential en cantidades locales para l-las dos interpretaciones son equivalentes. En multiprogramacin, cuando otros procesos activos pueden acceder y modificar la informacin comn mismo, las dos interpretaciones hacer una gran diferencia: En particular, para el lector con una amplia experiencia en uniprogramming esta observacin se ha insertado como una indicacin de las sutilezas de los juegos que son jugando. 2,3. A Interlude Lingstica. (Esta seccin puede omitirse en la primera lectura.) En la seccin 2.2. se describe la cooperacin de N procesos, en la estructura global se utiliz una secuencia vertical de puntos entre los soportes "parbegin" y "parend". Esto no es ms que un formalismo suelto, lo que sugiere al lector humano como componer en nuestra notacin un conjunto de N cooperantes procesos secuenciales, bajo la condicin de que el valor de N se ha fijado de antemano. Es una sugerencia para la construccin de 3, 4 o 5071 procesos cooperantes, no da una descripcin formal de N tales procesos cooperantes en el que N se produce como un parmetro, es decir, no es una descripcin, vlido para el valor de N. amy Es el propsito de esta seccin para mostrar que el concepto de la denominada "procedimiento recursivo" de ALGOL 60 es apto para esto. Este concepto se esbozar brevemente. Hemos visto cmo, despus de "empezar" declaraciones podran producirse con el fin de introducir y nombrar tanto varibles individuales (por enumeracin de sus nombres) o enteros ordenados establece variables af (a saber, en la declaracin del array}. Con el "llamado procedimiento de declaracin "podemos definir y nombrar una determinada accin, esa accin puede entonces ser invocados por el uso de su nombre como una declaracin, por lo que el suministro de los parmetros, para que la accin debe ser aplicada.

Como ejemplo consideramos el siguiente programa 6O ALGOL:

begin integer a, b; procedure square(u, v); integer u, v; begin u:= v * v end; L: square(a, 3); square(b, a); square(a, b) end .
En la primera lnea el nombre entero "a" y "b" se declaran. La siguiente lnea declara el procedimiento denominado "cuadrado", que opera en dos parmetros, que se especifican a ser enteros simples (y no, por ejemplo, las matrices completas). Esta lnea se llama "el procedimiento de la partida". La declaracin-la inmediatamente siguiente llamado "cuerpo del procedimiento" - describe, por definicin, la accin denominada: en la tercera lnea en la que el par de corchetes "begin .... end" es superfluo, se dice que la accin de "cuadrado "es asignar al parmetro primero el cuadrado del valor de la segunda. Luego, con la etiqueta "L", llega la primera declaracin. Antes de su ejecucin, los valores tanto de la "a" y "b" son indefinidos, despus de su ejecucin ", un 9 =". Despus de la ejecucin de la siguiente instruccin, el valor de "b" es por lo tanto = 81, despus de la ejecucin de la ltima sentencia, el valor de "a" es = 6561, el valor de "b" sigue siendo = 81. En el ejemplo anterior, el mecanismo de los procedimientos fue presentado esencialmente como un medio para la abreviatura, un medio para evitar tener que escribir el "cuerpo" tres veces, a pesar de que podra haberlo hecho con facilidad:
begin integer a, b; L: a:= 3 * 3; b:= a * a; a:= b * b end .

(En este ejemplo, la forma ms elaborada de la sentencia condicional se utiliza, a saber.:

if condition then statement 1 else statement 2 ,

lo que significa que si la "condicin" se cumple ", sentencia 1" se ejecuta y "declaracin de 2" se evitar, y que si "condicin" no se cumple, "Declaracin 1" se omite y "declaracin de 2" se ejecutar .) Se invita al lector a seguir el modelo de las llamadas de GCD y ver, cmo la variable "a" se convierte en = 3, sino que tambin est invitado a convencerse de que el patrn (dinmica) de las llamadas depende de los parmetros suministrados y que la sustitucin tcnica-replace llamada cuerpo-tal como se aplica en el ejemplo anterior podra dar lugar a dificultades aqu. Ahora vamos a escribir un programa para realizar una multiplicacin matriz * vector en el que 1) El orden del escalar M * Los productos escalares se pueden resumir en efecto prescrito (las filas de la matriz se explora de izquierda a derecha) 2) las N filas de la matriz se pueden procesar en paralelo.

(En caso de que no queremos imponer la restriccin de los valores puramente enteros, que hemos utilizado para declarador "real" en lugar de la sentencia declarativa "entero" y, adems, hemos introducido una matriz con dos subndices de una manera, esperamos, claro.) Se asume que, tras la entrada de este bloque de programa, los enteros "M" y "N" tienen valores positivos.
begin real array matrix[1 : N, 1 : M]; real array vector[l : M]; real array product[l : N]; procedure rowmult(k); value k; integer k; begin if k > O then parbegin begin real s; integer j; s:= 0; for j:= 1 step 1 until M do s:= s + matrix[k, j] * vector[j]; product[k]:= s end; rowmult(k -1) parend end; . . . . . rowmult(N); . . end

3. El problema de la exclusin mutua Revisited. Volvemos al problema de la exclusin mutua en vez de secciones crticas, tal como se hizo en la seccin 2.1 y generalizado en la seccin 2.2. En esta seccin se trata de una tcnica ms eficiente para la solucin de este problema, y slo despus de haberlo hecho, no tenemos los medios adecuados para la descripcin de ejemplos, con la que espero convencer al lector de la importancia fundamental y no del problema de la exclusin mutua. En otras palabras, hay que apelar a la paciencia del lector preguntando (sufrimiento, como yo, por la naturaleza secuencial de la comunicacin humana!) 3,1. La necesidad de una solucin ms realista. La solucin propuesta en la seccin 2,2 es interesante en la medida de lo que muestra que los medios restringidos de comunicacin proporcionados son, desde un punto de vista terico, suficiente para resolver el problema. Desde otros puntos de vista, que son tan caro a mi corazn, es totalmente inadecuada. Para empezar, que da lugar a una descripcin bastante engorroso de los procesos individuales, en la que es casi transparente que el comportamiento general es de acuerdo con el requisito conceptualmente tan simple de la exclusin mutua. En otras palabras, en una forma u otra esta solucin es una mistificacin enorme. Vamos a tratar de aislar en nuestras mentes en qu sentido esta solucin

representa de hecho una mistificacin, para esta investigacin podra dar la clave de la mejora. Tomemos el perodo de tiempo durante el cual uno de los procesos se encuentra en su seccin crtica. Todos sabemos que, durante ese perodo, ningn otro proceso puede entrar en su seccin crtica y que, si quieren hacerlo, tienen que esperar hasta que la ejecucin actual seccin crtica se ha completado. Para el resto de ese perodo difcil encontrar una actividad que se requiere de ellos: tienen que esperar de todos modos, y en lo que a nosotros respecta ", podran ir a dormir". Nuestra solucin no refleja en absoluto: nos mantenemos ocupados los procesos de ajuste y la inspeccin de variables comunes todo el tiempo, como si no hay un precio a pagar por esta actividad. Pero si nuestra aplicacin -i.e. las formas en que o los medios por los cuales estos procesos se llevan a cabo-es tal, que "duerme" es una actividad ms barato que este camino ocupado de esperar, entonces estamos plenamente justificados (ahora tambin desde el punto de vista econmico) para llame a nuestra solucin engaosa. En los ordenadores de hoy en da, hay al menos dos formas en las que esta forma activa de espera puede ser muy caro. Permtanme esbozar brevemente. Estas computadoras tienen dos partes diferenciadas, generalmente llamados "el procesador" y "la tienda". El procesador es la parte activa, en la que el operaciones aritmticas y lgicas se realizan, es "activo y pequeas", en la tienda, que es "pasivo y grandes" reside en cualquier momento la informacin, que no es procesada en la que muy momento, pero slo se mantiene all para futuras consultas. En el proceso de clculo de informacin total se transporta desde la tienda al procesador tan pronto como tiene que desempear un papel activo, la informacin en la tienda puede ser cambiado por el transporte en la direccin inversa. Tal ordenador es una herramienta muy flexible para la realizacin de procesos secuenciales. Incluso un equipo con un solo procesador nico puede ser usado para implementar una serie de procesos secuenciales concurrentes. Desde un punto de vista macroscpico, parecer como si todos estos procesos se llevan a cabo simultneamente, una inspeccin ms cercana revelar, sin embargo, que en cualquier "microscpicas" momento el procesador ayuda a lo largo de slo un nico programa, y slo la imagen global resultados, porque en momentos bien elegidos el procesador se cambiar desde un proceso a otro. En una implementacin de los diferentes procesos comparten el mismo procesador y de la actividad de uno de los procesos (es decir, una velocidad distinta de cero) implica una velocidad cero para los dems y es entonces deseable, que el tiempo de procesador precioso es consumida por los procesos, lo cual No podemos seguir de todos modos. Aparte de compartir el procesador, el intercambio tienda podra hacer que la actividad innecesaria de un proceso de espera indeseable. Supongamos que la inspeccin de o asignacin a una "variable comn" implica el acceso a una unidad de informacin-una as llamada "palabra" - en una tienda de ncleo de ferrita. El acceso a una palabra en un almacn de ncleo tarda un tiempo finito y por razones tcnicas slo una palabra se puede acceder a la vez. Cuando ms de un proceso

activo puede desear el acceso a palabras de la tienda mismo ncleo, la disposicin usual es que en el caso de coincidencia inmanente, las peticiones de acceso de almacenamiento de los procesos activos diferentes se conceden de acuerdo con un sistema incorporado en la regla de prioridad: la baja Prioridad del proceso se mantiene automticamente hacia arriba. (La literatura se refiere a esta situacin cuando se describe en "un canal de comunicacin robo de un ciclo de la memoria del procesador.) El resultado es que la inspeccin frecuente de las variables comunes puede ralentizar el proceso, las cantidades de locales que se almacenan en el almacn mismo ncleo . 3,2. Primitivas de Sincronizacin El origen de las complicaciones que conducen a soluciones tan complicadas como la que se describe en la seccin 2.2 es el hecho de que los accesos a las variables comunes indivisibles siempre estn "de un solo sentido de trfico de la informacin": un proceso individual puede asignar un nuevo valor o inspeccionar un valor de corriente. Tal inspeccin propiamente dicha, sin embargo, no deja ningn rastro de los otros procesos y la consecuencia es que, cuando un proceso desea reaccionar con el valor actual de una variable comn, su valor puede ser cambiado por los otros procesos entre el momento de su inspeccin y la efectuacin de la siguiente reaccin. En otras palabras: el conjunto anterior de las facilidades de comunicacin debe ser considerada como inadecuada para el problema en cuestin y debemos bloquear las alternativas mejor adaptadas. Tal alternativa est dada por la introduccin de a) entre los nmeros enteros variables comunes de propsito especial, que llamaremos "semforos". b) entre el repertorio de acciones, de las cuales los procesos individuales tienen que ser construidos, dos nuevas primitivas, lo que llamamos el "P-operacin" y el "V-operacin", respectivamente. Las ltimas operaciones siempre operan en un semforo y representan la nica forma en que los procesos concurrentes pueden acceder a los semforos. Los semforos son esencialmente enteros no negativos; cuando slo se utiliza para resolver el problema de la exclusin mutua, la gama de sus valores incluso se limita a "0" y "1". Es el mrito del fsico holands y Drs.CSScholten diseador equipo que ha demostrado un considerable campo de aplicacin para los semforos que tambin se puede realizar en los valores ms grandes. Cuando hay una necesidad de distincin, vamos a hablar de "semforos binarios" y "semforos generales", respectivamente. La definicin de la categora P-y V-operacin que yo le dar ahora, es insensible a esta distincin. Definicin. El V-operacin es una operacin con un argumento, que debe ser la identificacin de un semforo. (Si "S1" y "S2" denotan semforos, podemos escribir "V (S1)" y "V (S2)".) Su funcin es aumentar el valor de su argumento semforo por 1, este incremento debe ser considerado como una operacin indivisible. Tenga en cuenta que esta ltima frase "V (S1)" no equivalentes a "S1: = S1 + 1". Porque supongamos que dos procesos A y B contienen la declaracin "V (S1)" y que ambos gustara realizar esta declaracin en un momento en que, por ejemplo,

"S1 = 6". Excluyendo la interferencia con S1 de otros procesos, A y B se realizan sus operaciones en V en un orden no especificado-en por lo menos: fuera de nuestro control, y despus de la finalizacin de la segunda operacin V-el valor final de S1 ser = 8. Si S1 no haba sido un semforo, pero slo un entero comn ordinario, y si los procesos A y B contena la frase "S1: = S1 + 1" en lugar de la Voperacin en S1, entonces podra pasar lo siguiente. Proceso A evala "S1 + 1" y calcula "7"; antes de efectuar, sin embargo, la asignacin de este nuevo valor, el proceso B ha alcanzado el mismo nivel y tambin evala "S1 + 1", el clculo de "7". A partir de entonces ambos procesos se asigna el valor "7" para S1 y uno de los incrementos deseados se ha perdido. El requisito de la "operacin indivisible" se pretende excluir de este hecho, cuando el V-operacin se utiliza. Definicin. El P-operacin es una operacin con un argumento, que debe ser la identificacin de un semforo. (Si es "S1" y "S2" denotan semforos, podemos escribir "P (S1)" y "P (S2)".) Su funcin es disminuir el valor de su argumento semforo por 1 tan pronto como el valor resultante ser no negativo. La finalizacin de la operacin P--i.e. la decisin de que este es el momento apropiado para efectuar el descenso y la consiguiente disminucin en s-ha de considerarse como una operacin indivisible. Es la P-operacin, que representa el retardo potencial es decir,. cuando un proceso inicia una P-operacin en un semforo, que en ese momento es = 0, en ese caso, esto P-operacin no se puede completar hasta que otro proceso se ha realizado un V-funcionamiento en el mismo semforo y le ha dado el valor " 1 ". En ese momento, ms que un proceso puede haber iniciado un P-operacin en ese mismo semforo. La clusula de que la conclusin de una operacin de P-es una accin indivisible significa que cuando el semforo tiene el valor "1", slo uno de los iniciados P-operaciones en que se permite que se complete. Cul de ellos, de nuevo, se deja sin especificar, i, e, al menos fuera de nuestro control. En el estado actual de nuestros debates tomaremos la aplicabilidad de la P y V operaciones por sentado. 3,3. The Primitives Sincronizacin Aplicado al problema de la exclusin mutua. La solucin de los N procesos, cada uno con una seccin crtica, las ejecuciones de que se deben excluir unos a otros en el tiempo (ver seccin 2.2) es ahora trivial. Se puede hacer con la ayuda de un semforo binario, diga "libre". El valor de "libre" es igual al nmero de procesos permitidos de entrar en su seccin crtica ahora, o: "Libre = 1" significa: ninguno de los procesos se dedica a su seccin crtica "Libre = 0" significa: uno de los procesos se dedica a su seccin crtica. La estructura general de la solucin se convierte en:

begin integer free; free:= 1; parbegin process 1: begin...............end; process 2: begin...............end; . . . . process N: begin...............end; parend end with the i-th process of the form: process i: begin Li: P(free); critical section i; V(free); remainder of cycle i; goto Li end

4. El Semforo General. 4,1. Usos habituales de la Semaphore General. Consideramos dos procesos, que se llaman el "productor" y "consumidor", respectivamente. El productor es un proceso cclico y cada vez que pasa a travs de su ciclo se produce una cierta parte de informacin, que tiene que ser procesado por el consumidor. El consumidor tambin es un proceso cclico y cada vez que pasa a travs de su ciclo, se puede procesar la siguiente parte de la informacin, como se ha producido por el productor. Un ejemplo simple es dado por un proceso de computacin, produciendo como "partes de la informacin" imgenes perforadas tarjetas para ser perforados por una tarjeta perforada, que desempea el papel del consumidor. La relacin productor-consumidor implica un canal de comunicacin unidireccional entre los dos procesos, a lo largo de la cual las partes de la informacin se puede transmitir. Suponemos que los dos procesos a ser conectados para este propsito a travs de un tampn con capacidad ilimitada, es decir, las porciones producidas no necesitan ser consumido inmediatamente, pero pueden cola en la memoria intermedia. El hecho de que ningn lmite superior se ha dado por la capacidad de la memoria intermedia hace que este ejemplo un poco irreal, pero esto no debera preocuparnos demasiado ahora. (El origen del nombre "buffer" se hace comprensible en cuanto se investigan las consecuencias de su ausencia, es decir, cuando el productor slo puede ofrecer su porcin siguiente despus de la parte anterior ha sido realmente consumidas en el ordenador -.. Tarjeta de sacador ejemplo, se puede suponer que la tarjeta perforada puede perforar tarjetas a una velocidad constante, por ejemplo 4 tarjetas por segundo. Supongamos, que esta velocidad de salida se acopla bien con la velocidad de produccin, es decir, que el ordenador puede realizar la imagen de la tarjeta con el proceso de produccin misma velocidad media. Si la conexin entre el proceso de computacin y tarjetas perforadas es sin memoria intermedia, entonces la pareja slo funciona continuamente a toda velocidad cuando el

proceso de produccin de tarjetas produce una tarjeta de cada cuarto de segundo. Si, sin embargo, la naturaleza del proceso de computacin es tal, que despus de calcular uno o dos segundos vigorosa que produce 4 a 8 imgenes de las tarjetas en una sola rfaga, entonces la conexin no tamponada resultar en un perodo de tiempo, en el que el punzn se mantendr inactiva (por falta de informacin), seguido un perodo en el que el proceso de computacin tiene que estar inactivo, puesto que no puede deshacerse de la imagen de la carta siguiente, antes de la anterior ha sido en realidad perforado. Dichas irregularidades en la velocidad de produccin, sin embargo, pueden ser suavizadas por un buffer de tamao suficiente y es decir, por qu un dispositivo de cola se llama "buffer"). En esta seccin no se ocupar de las diferentes tcnicas de la implementacin de un buffer. Debe ser capaz de contener porciones sucesivas de informacin, por lo tanto, debe ser un medio de almacenamiento adecuado, accesible a ambos procesos. Adems, no slo debe contener las propias porciones, tambin debe representar a su ordenacin lineal. (En la literatura dos conocidas tcnicas se describen por "bfer cclico" y "cadena", respectivamente.) Cuando el productor ha preparado su porcin prxima que se aaden a la memoria intermedia, se indicar esta accin simplemente por "aadir porcin para amortiguar ", sin entrar en ms detalles, de manera similar, el consumidor va a" tomar parte de la memoria tampn ", donde se entiende que va a ser la porcin ms antigua, todava en la memoria intermedia. (Otro nombre de un bfer es un "primero en entrar, primero en salirMemory). Omitiendo en el bloque ms exterior las declaraciones de la memoria intermedia, que ahora puede construir los dos procesos con la ayuda de un semforo general nico, llamado "nmero de porciones de cola".
begin integer number of queuing portions; number of queuing portions:= 0; parbegin producer: begin again 1: produce the next portion; add portion to buffer; V(number of queuing portions); goto again1 end; consumer: begin again 2: P(number of queuing portions); take portion from buffer; process portion taken; goto again 2 end parend end

La primera lnea del productor representa la codificacin del proceso que forma la porcin prxima de la informacin, sino que puede ser concebido-it tiene un significado independiente-quite de la memoria intermedia para la cual est destinada esta porcin, cuando se ha ejecutado la porcin prxima se ha completado con xito, la terminacin de su construccin ya no puede ser dependiente de otros (no mencionado) condiciones. La segunda lnea de codificacin representa las acciones, que definen las porciones de acabados, como

la siguiente en la memoria intermedia, despus de su ejecucin la parte de nuevo ha sido aadido completamente en el bfer, aparte del hecho de que el consumidor no lo saben todava. El V-operacin finalmente confirma su presencia, es decir, que indica al consumidor. Nota, que es absolutamente esencial, que el V-operacin es precedida por la adicin completa de la porcin. Acerca de la estructura del consumidor Observaciones anlogas se pueden hacer. Particularmente en el caso de aplicacin tampn por medio de encadenamiento no es inusual que las operaciones de "aadir porcin de amortiguacin" y "tomar parte de la memoria tampn"-operativo como estn en la misma informacin de estado de la memoria intermedia clerical-podra interferir con cada uno otro de la manera ms deseable, a menos que veamos a la misma, que se excluyen mutuamente en el tiempo. Esto puede ser atendidas por un semforo binario, llamado "manipulacin de amortiguacin", los valores de lo que significa: = 0: o bien aadir o quitar de la memoria intermedia est teniendo lugar = 1: sin aadir ni toma de la memoria intermedia est teniendo lugar. El programa es el siguiente:
begin integer number of queuing portions, buffer manipulation; number of queuing portions:= 0; buffer manipulation:= 1; parbegin producer: begin again 1: produce next portion; P(buffer manipulation) ; add portion to buffer; V(buffer manipulation); V(number of queuing portions); goto again 1 end; consumer: begin again 2: P(number of queuing portions); P(buffer manipulation); take portion from buffer; V(buffer manipulation); process portion taken; goto again 2 end parend end

Al lector se le pide a convencerse de que a) el orden de las dos operaciones en V en el productor es inmaterial b) el orden de las dos operaciones P-en el consumidor es esencial. Observacin. La presencia de la "manipulacin buffer" semforo binario tiene otra consecuencia. Hemos dado el programa de un productor y un consumidor, pero ahora la extensin a ms productores y consumidores / o ms es muy simple: el mismo semforo se encarga de que dos o ms adiciones de nuevas porciones nunca se mezclan y se aplica el mismo a dos o ms tomas de una parte por los

consumidores diferentes. El lector se solicita para verificar que el orden de las dos operaciones en V en el productor es todava inmaterial. 4,2. La abundancia de la Semforo General. En esta seccin vamos a mostrar la superfluidad del semforo general y lo haremos por volver a escribir el ltimo programa de la seccin anterior, utilizando semforos binarios solamente. (Intencionalmente he escrito "veremos" y no "vamos a demostrar lo superfluo". No tenemos a nuestra disposicin el aparato matemtico que se necesitara para dar una prueba y no me siento inclinado a desarrollar aparato matemtico tal ahora. Pero tengo la esperanza de que mi programa sea convincente!) En primer lugar, deber dar una solucin y aplazar el debate hasta despus.
begin integer numqueupor, buffer manipulation, consumer delay; numqueupor:= 0; buffer manipulation:= 1; consumer delay:= 0; parbegin producer: begin again 1: produce next portion; P(buffer manipulation); add portion to buffer: numqueupor:= numqueupor + 1; if numqueupor = 1 then V(consumer delay); V(buffer manipulation); goto again 1 end; consumer: begin integer oldnumqueupor; wait: P(consumer delay); go on: P(buffer manipulation); take portion from buffer; numqueupor:= numqueupor -1; oldnumqueupor:= numquepor; V(buffer manipulation) ; process portion taken; if oldnumqueupor = 0 then goto wait else goto go on end parend end . Relevantes en el comportamiento dinmico de este programa son los periodos de

tiempo durante el cual el buffer est vaco. (Siempre y cuando el tampn no est vaco, el consumidor puede seguir felizmente a su velocidad mxima.) Este plazo slo puede ser iniciado por el consumidor (tomando la presente ltima porcin de la memoria intermedia), slo puede ser terminado por el productor (mediante la adicin de una porcin de un bfer vaco). Estos dos acontecimientos se puede detectar de forma inequvoca, gracias a la "manipulacin tampn" semforo binario, que garantiza la exclusin mutua necesaria para esta deteccin. Cada perodo se acompaa de un P-V-y un funcionamiento en el "retardo consumidor" binario semforos. Por ltimo, llamamos la atencin a la variable local "oldnumqueupor" del consumidor: su valor se establece durante la toma de la parte

fija y, si se trataba de la ltima porcin entonces presente. (Los lectores ms expertos ALGOL ser consciente de que slo tenemos que almacenar un bit de informacin, a saber, si la disminucin de numqueupor dio lugar a un valor = 0;.. Podramos haber utilizado una variable local de tipo Boolean para este fin) Cuando el consumidor decide ir a "esperar", es decir, se encuentra "oldnumqueupor = 0" en ese momento "numqueupor" ya de por s podra ser mayor que cero otra vez! En el programa anterior, el hecho relevante fue el perodo con bfer vaco. Se puede observar que el vaco es, en s mismo, ms bien irrelevante: lo nico que importa, cuando el consumidor gustara tomar una porcin prxima, que todava est ausente. Vamos a programar esta versin tambin. En su comportamiento dinmico podemos esperar menos P y V-en las operaciones "retraso del consumidor", a saber. no cuando el buffer se vaca desde hace un tiempo, pero se llena de nuevo en el momento de hacer retardo del consumidor innecesario. De nuevo, primero debern dar el programa y luego el debate.
begin integer numqueupor, buffer manipulation, consumer delay; numqueupor:= 0; buffer manipulation:= 1; consumer delay:= 0; parbegin producer: begin again 1: produce next portion; P(buffer manipulation); add portion to buffer; numqueupor:= numqueupor + 1; if numqueupor = 0 then begin V(buffer manipulation); V( consumer delay) end else V(buffer manipulation); goto again 1 end; consumer: begin again 2: P(buffer manipulation); numqueupor:= numnqueupor -1; if numqueupor = -1 then begin V(buffer manipulation); P(consumer delay); P(buffer manipulation) end; take portion from buffer; V(buffer manipulation); process portion taken; goto again 2 end parend end

Una vez ms, el semforo "manipulacin buffer" es apto para la exclusin mutua de secciones crticas. Los ltimos seis lneas del productor podra haber sido formulado como sigue: si numqueupor = 0, entonces V (retardo de los consumidores); V (buffer manipulacin); GOTO de nuevo 1 Al no hacerlo, he seguido un gusto personal, a saber. para evitar la P y V operaciones dentro de las secciones crticas, el gusto personal a la que el lector no

debe prestar demasiada atencin. El rango de valores posibles de "numqueupor" se ha ampliado con el valor "-1", es decir, (fuera de la ejecucin de la seccin crtica) "el buffer no es slo vaco, pero su vacio ya ha sido detectado por el consumidor, que ha decidido esperar ". Este hecho puede ser detectado por el productor cuando, despus de la adicin de una ", numqueupor = 0" sostiene. Ntese cmo, en el caso de "numqueupor = -1" de la seccin crtica del consumidor de forma dinmica dividida en dos partes: esto es lo ms esencial, pues de lo contrario el productor nunca tendra la oportunidad de aadir la parte que ya est muy querido por el consumidor. (El programa que acabamos de describir se conoce como "El Barbero Durmiente". Hay una peluquera con una sala de espera separada. La sala de espera tiene una entrada y junto a ella una salida a la habitacin con la silla del barbero, la entrada y salida de compartir el mismo puerta corredera que cierra siempre uno de ellos y, adems de la entrada es tan pequea que slo un cliente puede entrar en l a la vez, fijando as su orden de entrada las exclusiones mutuas son as garantizado..

Cuando el peluquero ha terminado un corte de pelo, abre la puerta a la sala de espera y lo inspecciona. Si la sala de espera no est vaco, se invita al prximo cliente, de lo contrario se va a dormir en una de las sillas de la sala de espera. El comportamiento complementario de los clientes es el siguiente: cuando se dan cero o ms clientes en espera vagar, que slo tiene que esperar su turno, cuando se dan cuenta, sin embargo, el Barbero Durmiente - "numqueupor = -1" - que despertarlo. ) Los dos programas propuestos presentan un fuerte indicio a la conclusin de que el semforo general es, de hecho, superflua. No obstante, no Shaal tratar de suprimir el semforo general: la restriccin de sincronizacin de un solo lado expresable por que es muy comn y la comparacin de las soluciones con y sin semforo general muestra convincentemente que debe considerarse como una herramienta adecuada. 4,3. El bfer limitado. Voy a dar un ejemplo simple pasada para ilustrar el uso del semforo general. En la seccin 4.1 hemos estudiado un productor y un consumidor acoplado a travs de un buffer con capacidad ilimitada. Esta es una restriccin general de un solo lado: el productor puede ser arbitrariamente muy por delante de los consumidores, por el contrario el consumidor nunca puede estar por delante del productor. La

relacin se vuelve simtrica, si los dos estn acoplados a travs de un buffer de tamao finito, por ejemplo porciones N. Damos el programa sin ningn debate; pedimos al lector convencerse a s mismo de la simetra completa. ("El consumidor produce y consume el productor posiciones vacas en el buffer".) El valor de N, como el tampn, se supone que se define en el universo circundante en el cual debe ser el siguiente programa incorporado.
begin integer number of queuing portions, number of empty positions, buffer manipulation; number of queuing portions:= 0; number of empty positions:= N; buffer manipulation:= 1; parbegin producer: begin again 1: produce next portion; P(number of empty positions); P(buffer manipulation); add portion to buffer; V(buffer manipulation); V(mumber of queuing portions); goto again 1 end; consumer: begin again 2: P(number of queuing portions); P(buffer manipulation); take portion from buffer; V(buffer manipulation) ; V(number of empty positions); process portion taken; goto again 2 end parend end