Apuntes SITR

1. Sistemas Informáticos de Tiempo Real 1

1.1. Definición 1

1.2. Tiempo Real VS Rapidez 1

1.3. Sistemas Informáticos de Tiempo Real y Sistemas Empotrados 1

1.4. Sistemas Informáticos de Tiempo Real Estrictos y No Estrictos 2

1.5. Tolerancia a Fallos 3

1.6. Sistemas Controlados por Eventos o por Tiempo 4

2. Ejemplos de Sistemas Informáticos de Tiempo Real 4

3. Características de los Sistemas Informáticos de Tiempo Real 5

3.1. Grandes y Complejos 5

3.2. Manipulación de Magnitudes Físicas 5

3.3. Extremadamente Fiables y Seguros 5

3.4. Concurrencia 6

3.5. Herramientas de Manejo en Tiempo Real 6

3.6. Implementación Eficiente 7

3.7. Lenguajes de Programación 7

Sistemas Informáticos en Tiempo Real Tema I

Tema I Introducción a los SISTEMAS INFORMÁTIC OSDE TIEMPO REAL

1

1. Sistemas Informáticos de Tiempo Real. 1.1. Definición.

Se trata de aquellos sistemas capaces de captar estímulos generados por el entorno y dar una respuesta a éstos en un periodo de tiempo finito especificado.

Se puede observar que en la definición se destacan dos aspectos que

definen y diferencian los Sistemas Informáticos de Tiempo Real de los demás:

• Tiempo de respuesta: Es un aspecto clave ya que “no importa que sea capaz de generar la respuesta correcta sino que ésta se produzca en un tiempo determinado”.

Por ejemplo, de nada sirve un airbag si éste se pone en funcionamiento después de un choque. • Lógica de respuesta: El sistema debe interactuar con el entorno

adquiriendo estímulos y estados de entorno, y generando una acción sobre dicho entorno.

Estas dos características provocan que el Sistema Informático de Tiempo Real deba tener un comportamiento general a expensas de los eventos que ocurran. Esta es la dificultad de los Sistemas Informáticos de Tiempo Real puesto que para ello debemos hacer que los componentes trabajen juntos ante la aparición de eventos no predecibles, fallos... 1.2. Tiempo Real VS Rapidez.

Generalmente, se confunden los términos de Sistema Informático de

Tiempo Real y sistema rápido. Todos los programas deben ser lo suficientemente rápidos como para cumplir los requisitos de los usuarios, pero el hecho de que un programa sea rápido no significa que sea de tiempo real. Tiempo real significa trabajar con la distribución física de los componentes, con el manejo de estímulos impredecibles, con fallos en los componentes, con la incertidumbre acerca del entorno y con el rendimiento y robustez del sistema. Un Sistema Informático de Tiempo Real debe ser lo suficientemente rápido, pero es sólo una parte a tener en cuenta. 1.3. Sistemas Informáticos de Tiempo Real y Sistemas Empotrados.

Para conseguir el propósito para el cual se ha diseñado un Sistema

Informático de Tiempo Real, los componentes interactúan entre sí y con el entorno intercambiando información y compartiendo recursos, modificando su comportamiento.



2

El entorno lo podemos descomponer en dos partes:

• El entorno activo es donde se engloban los operadores que intervienen en el comportamiento del sistema modificando el modo de operación.

• El entorno pasivo comprende a los usuarios interesados solamente

en el servicio proporcionado, y al ambiente exterior que no tiene nada que ver con la existencia del sistema.

Los sistemas empotrados son aquellos que no precisan de un entorno

activo. Además, existen otros sistemas considerados sistemas empotrados. Estos son los subsistemas que forman parte de un sistema ya que no es posible una intervención directa del operador y la funcionalidad debe ser soportada completamente desde su interior. 1.4. Sistemas Informáticos de Tiempo Real Estrictos y No Estrictos.

En los Sistemas Informáticos de Tiempo Real se requiere tanto que el resultado sea correcto como que se genere en un tiempo determinado. Con respecto a la corrección lógica podemos decir que suele expresarse en términos de salidas y entradas correctas.

En función de la importancia que se le de a la corrección temporal en un Sistema Informático de Tiempo Real se puede realizar la siguiente clasificación:

• SISTEMAS ESTRICTOS: Son aquellos sistemas en los que el tiempo es tan importante que no puede ser sacrificado por una mejora en otros aspectos. En algunos sistemas, la corrección temporal llega a ser tan crítica, es decir, tan importante, que la corrección lógica puede ser relajada en aras de alcanzar un tiempo de respuesta determinado. Por ejemplo, el chequeo de la altitud de una aeronave automática en tiempos prescritos puede tener consecuencias catastróficas a no ser que la respuesta llegue aunque sea de mala calidad.

• SISTEMAS NO ESTRICTOS: En este caso, la corrección temporal

ya no es un aspecto crítico. Si se produce un fallo provocando un retardo en la llegada de información, éste no provoca consecuencias serias en el funcionamiento general del sistema. Las tareas catalogadas como no estrictas se ejecutarán lo más rápido que sea posible, pero sin estar forzadas por tiempos límites, pudiendo ser sacrificada la corrección temporal bajo ciertas circunstancias.



3

En general, un sistema puede estar constituido por una combinación de tareas de ambos tipos mediante una jerarquía de prioridades y permitiendo la relajación temporal de aquellas tareas que lo permitan. O también puede estar formado por tareas con tiempos estrictos y no estrictos a la vez, es decir, la respuesta a un evento puede tener un tiempo límite no estricto de 50 ms (para asegurar un funcionamiento óptimo) y uno estricto de 200 ms (para evitar posibles daños a los usuarios o al funcionamiento del sistema). Cada vez que pasa tiempo se produce una pérdida general de la calidad de la información. A sí mismo, se pueden definir dos tipos de relajación temporal:

• Si no se cumple el tiempo límite la información pierde completamente su valor. En tareas periódicas puede ser admisible que se pierda la ejecución de alguna de ellas.

• Puede ocurrir que el servicio llegue tarde pero éste sea válido para una cierto intervalo de tiempo.

ESTRICTO NO ESTRICTO

Impone un tiempo de respuesta determinista.

Impone un tiempo de respuesta pero no determinista.

En caso de sobrecarga no se degrada la respuesta

En caso de sobrecarga se degrada la respuesta.

Trabaja con volúmenes de datos pequeños

Trabaja con volúmenes de datos grandes.

1.5. Tolerancia a Fallos.

A pesar de que los sistemas están diseñados para que generen un resultado correcto y dentro de un intervalo determinado, éstos pueden fallar exhibiendo así un comportamiento para el cual no fueron diseñados. Ya que los fallos son inevitables, un sistema debe ser robusto frente a ellos, es decir, debe presentar un comportamiento de “tolerancia a fallos”. En función del comportamiento en caso de fallo, los sistemas se pueden clasificar como:

• SISTEMAS CON PARADA SEGURA: En caso de fallo se coloca al sistema en un estado seguro de parada. Son aquellos en los cuales un error puede tener consecuencias catastróficas.

• SISTEMAS CON DEGRADACIÓN ACEPTABLE: En caso de fallo,

presentan un funcionamiento parcial con pérdida de funcionalidad o prestaciones, aunque el sistema puede seguir funcionando a pesar de esa merma.



4

1.6. Sistemas Controlados por Eventos o por Tiempo.

Otra clasificación está basada en el uso de eventos o de ciclos de reloj como controlador de la ejecución de las diversas tareas. Existen dos tipos:

• ARQUITECTURA CONTROLADA POR EVENTOS (“event-driven” o

“interrupt-driven”): Se establece la ejecución de un componente basándose en la aparición de una interrupción o señal generada por un evento externo.

Por ejemplo, un robot móvil que se mueve por el espacio ante la aparición de un obstáculo ejecuta la tarea de evitarlo que hasta entonces estaba dormida.

• ARQUITECTURA CONTROLADA POR TIEMPO (“time-driven”):

Opera tratando los pulsos regulares del reloj como si fueran señales de interrupción. Cuando el reloj alcanza ciertos valores predefinidos, una acción apropiada es seleccionada para su ejecución.

Ambos tipos de arquitectura tienen sus ventajas y sus desventajas. Los

sistemas manejados por tiempo son más sencillos y robustos puesto que permiten interfaces entre subsistemas muy controlados y con un funcionamiento independiente mientras que los sistemas basados en interrupciones son sistemas más eficaces para responder a eventos externos no regulares. 2. Ejemplos de Sistemas Informáticos de Tiempo Real. Robótica: Los robots son vehículos que se desplazan por un espacio de trabajo y que interactúan con el entorno. El seguimiento de trayectorias, la planificación de trayectorias libres de obstáculos y seguimientos de blancos, son tareas que deben responder ante ciertos estímulos en un periodo de tiempo. Automoción: La industria del automóvil ha cambiado de tal manera que los sistemas que antes se basaban totalmente en conceptos mecánicos, hoy en día han pasado a un estado donde los componentes electrónicos juegan un papel muy importante. Sistemas como el de inyección electrónica, el de control de encendido o el de antibloqueo tienen al computador como un elemento que debe reaccionar en tiempo real ante eventos generados por el entorno.

Figura 1.1. Aplicaciones de control de robots



5

Por ejemplo, la centralita de inyección debe mostrar variables de velocidad, aceleraciones, revoluciones y temperatura para determinar la inyección de combustible óptima. El sistema antibloqueo de frenos controla la velocidad de cada rueda y las aceleraciones para regular la presión adecuada sobre los discos de freno para evitar el bloqueo y minimizar la distancia de frenado.

3. Características de los Sistemas Informáticos de Tiempo Real. 3.1. Grandes y Complejos.

Escribir pequeños programas no presenta ninguna complejidad pudiendo hacerlo una sola persona la mismo tiempo que no es muy complicado que otra persona sea capaz de comprender su diseño y funcionamiento. Por eso se dice que los pequeños programas se escriben de forma casi artesanal. A pesar de esto, se deben seguir ciertas normas de diseño y codificación: BUEN ESTILO.

Para referirnos al término grande, usaremos la palabra variedad, es decir, si un sistema es grande se dice que tiene mucha variedad. La variedad puede ser las necesidades y actividades del mundo real que se reflejan en el funcionamiento del programa. Puesto que la naturaleza está cambiando constantemente, los programas que exhiben una gran variedad deben cambiar también. Puesto que los Sistemas Informáticos de Tiempo Real deben responder ante eventos, deben ser grandes y complejos para poder atender cualquier tipo de evento. 3.2. Manipulación de Magnitudes Físicas.

Sabemos que un Sistema Informático de Tiempo Real debe controlar actividades del entorno mediante captura o activación de variables físicas.

Las señales físicas suelen ser analógicas por lo que deben ser convertidas a información digital manejable por el computador. Para la captura de señales se requiere un muestreo (adquisición de valores) y una cuantificación (codificación en niveles). El período de muestreo (intervalo de tiempo transcurrido entre dos capturas sucesivas) depende del tipo de señal. 3.3. Extremadamente Fiable y Seguro.

Es necesario tener como directriz para el diseño de Sistemas

Informáticos de Tiempo Real la FIABILIDAD y la SEGURIDAD, ya que muchos controlan funciones vitales.

Figura 1.2. Sistema de control de encendido de un automóvil



6

Un fallo en el generador de energía eléctrica que suministra la unidad de cuidados intensivos puede ser catastrófico. Un error del controlador de una planta química puede provocar daños graves en los equipos o en el medio ambiente. Esto nos dice que tanto el hardware como el software que operan en estos sistemas deben ser extremadamente fiables y seguros. Tienen en cuenta hasta el posible error humano. 3.4. Concurrencia.

Se trata de capacidad de un sistema para mantener varias tareas en

estados intermedios de ejecución. Puesto que pueden ocurrir dos o más eventos de forma paralela, nuestro Sistema Informático de Tiempo Real debe tener la capacidad de atenderlos de forma paralela.

SISTEMAS DE TIEMPO COMPARTIDO: Se trata de aquellos sistemas que, por tener sólo una CPU, no pueden realizar tareas simultáneamente pero pueden mantener varias tareas en un punto intermedio de ejecución, ejecutando de forma alternativa.

SISTEMAS MULTIPROCESADORES: Permiten la ejecución de tareas de forma simultánea de forma paralela. SISTEMAS DISTRIBUIDOS: Permite el paralelismo y los computadores se encuentran interconectados y geográficamente dispersos. Debido a las dificultades y problemas que entraña permitir a un programador que cree programas para sistemas con carácter concurrente se ha optado por emplear otras herramientas de trabajo como las que aportan lenguajes como Occam o ADA95 o por sistemas operativos como UNIX. 3.5. Herramientas de Manejo en Tiempo Real.

Es muy difícil diseñar sistemas que garanticen una respuesta apropiada en el tiempo apropiado para toda condición. Por eso, los Sistemas Informáticos de Tiempo Real se construyen con ciertos márgenes sobrantes, de modo que este no produzca retardos en los períodos críticos ni en el peor de los casos. Es preciso que se disponga de un soporte que permita:

- Especificar el tiempo de ejecución de cada tarea. - Especificar el tiempo de finalización de cada tarea. - Responder a situaciones donde no se cumplen los requerimientos

temporales. - Responder a situaciones donde los experimentos temporales no

varíen.



7

3.6. Implementación Eficiente.

La eficiencia debe ser un objetivo en los Sistemas Informáticos de Tiempo Real.

3.7. Lenguajes de Programación.

Lenguaje ensamblador:

• Muy Eficiente • Difícil de implementar la concurrencia.

Lenguajes secuenciales de alto nivel:

• C, C++, Java, Pascal, Fortran, Jovial, Coral, RTL/2. • Portables, y fáciles de programar. • Lo incorporan soporte para la concurrencia (debe ser soportado

por el S.O.).

Lenguajes concurrentes de alto nivel:

• ADA95, Modula-2, PEARL, Mesa, CHILL. • Soprte de la concurrencia y especificaciones temporales en el

propio lenguaje.

Comportamiento Temporal

Modelo del Entorno

Métodos Formales

Descomposición Abstracción

Diseño General

Diseño de Detalle

Implementación de Prototipos

Test del Prototipo

Implementación Final

Verificación

Especificación de requerimientos

Figura 1.3. Fases en el diseño de una aplicación

1

Sistemas Informáticos de Tiempo RealSistemas Informáticos de Tiempo RealISA-UMH © T-98-001V1.0

1

SITR:Introducción

Definición de S. Tiempo Real

ü Un Sistema de Tiempo Real se define como:û “Un sistema que debe responder ante estímulos generados por el entorno

dentro de un periodo de tiempo finito especificado”

ü Aspectos fundamentales:û Son sistemas que interactúan con el entorno (mundo físico), adquiriendo

estímulos y estados del entorno y generando una acción sobre dicho entorno.

û Son sistemas en los que el tiempo de respuesta es un aspecto crítico.

ü Corrección:û Lógica

û Temporal


2

SITR:Introducción

Tiempo Real / Rapidez

ü Todo sistema de tiempo real debe ser suficientemente rápido paracumplir los requerimientos, pero el que un sistema sea rápido noimplica que éste sea de tiempo real

ü La rapidez de un sistema de tiempo real está fijada por la naturaleza de los estímulos con los que tiene que tratar, la cual puede variar de unas aplicaciones a otras.

ü Tiempo real significa trabajar con aspectos del sistema como distribución física de los componentes, manejo de estímulos impredecibles, fallos en los componentes, incertidumbre acerca del entorno, y el efectos de estos aspectos sobre el rendimiento y robustez del sistema.

2


3

SITR:Introducción

Sist. Tiempo Real / Sist. Empotrados

ü Entorno de un SITR:• entorno activo que comprende los operadores que intervienen en el

comportamiento del sistema modificando el modo de operación.

• entorno pasivo que comprende a los usuarios que están solamente interesados en el servicio proporcionado y al ambiente exterior que no tiene nada que ver con la existencia del sistema.

ü Sistema empotrado (“embedded system”)û Unicamente tiene un entorno pasivoû Es un componente autónomo que forman parte de un sistema mayorû Ejemplos:

• Disco duro

• Lavadora

• Automóvil

• Sonda espacial

• Equipos médicos


4

SITR:Introducción

STR Estrictos/ No Estrictos


û Temporal

ü STR estrictos (críticos):la corrección temporal es crítica. û El tiempo de respuesta es muy importante y no puede ser sacrificado por

una mejora en otros aspectos. û En ciertos sistemas (p.e. sistemas de seguridad críticos) la corrección

temporal es tan importante que el criterio de corrección lógica puede ser relajado en aras de alcanzar un tiempo de respuesta determinado

ü STR no estrictos (acríticos):la corrección temporal no es crítica. û Fallos ocasionales en generar un resultado dentro del tiempo fijado no

produce consecuencias serias en el funcionamiento general del sistema.û Las tareas de tiempo real no estrictas son ejecutadas tan rápido como es

posible, pero no están forzadas por tiempos límite absolutos, pudiendo ser sacrificada la corrección temporal bajo ciertas circunstancias

3


5

SITR:Introducción

ü Un STR puede estar formado por tareas críticas y acríticasü Una misma tarea puede tener tiempos límite estrictos y no estrictos.

û La respuesta a un evento de peligro puede tener un tiempo límite no estricto de 50 ms (para una reacción con eficiencia óptima) y un tiempo límite estricto de 200 ms (para garantizar que no se produce un daño en el equipo o en las personas). Entre estos dos límites, el valor o utilidad de la salida decrece según aumenta el tiempo.

ü Tipos de relajación en la corrección temporal:• Si no se cumple el tiempo límite el resultado no tiene ningún valor (pérdidas

ocasionales de respuestas a eventos)

• Que el servicio llegue tarde ocasionalmente pero este sea valido dentro de un cierto intervalo de tiempo.

STR Estrictos/ No Estrictos


6

SITR:Introducción

Tolerancia a Fallos


û Temporal

ü Los sistemas pueden fallar, es decir exhibir un comportamiento para el cual no fueron diseñados.

û Ya que los fallos son inevitables, un sistema de tiempo real debe ser robusto frente a ellos, comportamiento denominado ‘tolerancia a fallos’.

ü Tipos de Sistemas:û Sistemas con parada segura (“fail-safe”): en caso de fallo colocan al sistema

en un estado seguro (sistemas críticos)û Sistemas con degradación aceptable (“fail-soft”): presentan una pérdida

parcial de funcionalidad o prestaciones en caso de fallo, pudiendo seguir funcionando a pesar de dicha merma.

4


7

SITR:Introducción

STR Eventos / Tiempo

• Arquitectura controlada por eventos o interrupciones (“event-driven” o “interrupt-driven”).

û Establece la ejecución de un componente o tarea basándose en la aparición de una interrupción o señal generada por un evento externo

û Constituyen un mecanismo mucho más eficaz para responder ante eventos externos no regulares.

• Arquitectura controlada por tiempo (“time-driven”).

û Opera de acuerdo a los ciclos del reloj o relojes del sistema.

û Este tipo de sistemas se utiliza cuando es preciso la ejecución de tareas periódicas o la ejecución de tareas mediante temporizadores.

û Son más sencillos y robustos (interfaces entre subsistemas muy controlados y con un funcionamiento independiente basado en relojes locales)


8

SITR:Introducción

Ejemplos de STR

ü Control de Procesos (1)

ActuadorVálvula

Sensor de nivel

A/D

D/A

Ref.

+

-

Acondicionamientode señal

Regulador

Figura 1.1 Sistema de regulación de nivel de un depósito

Tiempo

5


9

SITR:Introducción

ü Control de Procesos (2)

Ejemplos de STR

Materiales

Prodcutofinal

Sensores TemperaturaAgitadores

Figura 1.2 Sistema de Control de procesos jerarquizado


10

SITR:Introducción

ü Fabricación:û Integración del proceso de fabricación (CIM)

Ejemplos de STR

Prodcutofinal

Materiales

Figura 1.3 Sistema de control de producción.

6


11

SITR:Introducción

ü Sistemas de Comunicacionesû Redes de Datos

• Protocolos (conjunto de reglas que controlan la comunicación entre dos equipos).

• Los protocolos son algoritmos que deben interaccionar con el entorno reaccionando ante eventos externos (llegada de mensajes, peticiones, errores, confirmaciones).

û Redes Telefónicas

ü Sistemas de Control de Vuelo

Ejemplos de STR


12

SITR:Introducción

ü Robóticaû Control dinámico

û Planificación de trayectorias

Ejemplos de STR

Figura 1.4 Aplicaciones de control de robots

7


13

SITR:Introducción

ü Automoción:û Control de encendido

û Control de inyecciónû Antibloqueo de frenos ABSû Control de tracción ASRû Airbagû Suspensión activa

Ejemplos de STR


14

SITR:Introducción

ü Realidad Virtualû Responde ante las acciones del entorno físico (movimientos, voz, mirada,...)

generando un conjunto completo de estímulos que es realimentado al propio operador (sonido, movimiento, imagen, tacto,....), todo ello dentro de un tiempo finito

ü Otros sistemas empotrados

Ejemplos de STR

Interfaz

Sistema Empotrado

Sistema de IngenieríaAlgoritmos

de control

Acceso a los datos

DispositivosVisualizadores

Recuperaciónde datos

Interfaz del operador

Consola

Sistema de Supervisión

remoto

Reloj deTiempo Real

Basede Datos

Figura 1.6 Sistema empotrado típico

8


15

SITR:Introducción

Características de un STR

ü Grandes y complejos.

ü Manipulación de magnitudes físicas.

ü Estremadamente fiable y seguro.

ü Concurrencia.

ü Herramienas para el manejo de tiempo real.

ü Implementación eficiente.


16

SITR:Introducción

Concurrencia

ü La concurrencia se define como la capacidad de un sistema de mantener varias tareas en estados intermedios de su ejecuciónû Sistemas de tiempo compartido

û Sistemas multiprocesadoresû Sistemas distribuidos

ü Expresión de la concurrencia en un programa:û El programadorû El lenguaje de programación (ADA95, Occam, Pearl...)û El sistema operativo (POSIX)

9


17

SITR:Introducción

Herramientas de Tiempo Real

ü Los sistemas se diseñan en con unos márgenes de capacidad sobrantes, de forma que el comportamiento en “el peor caso” no produzca retardos en los periodos críticos de operación del sistema.

ü Soporte que permita:

• Especificar el tiempo en el cual debe ejecutarse cada tarea

• Especificar el tiempo en el cual debe se completada cada tarea

• Responder a situaciones en las cuales no se pueden cumplir todos los requerimientos temporales

• Responder a situaciones en las cuales los requerimientos temporales puedan variar dinámicamente


18

SITR:Introducción

Diseño de STR

ü Metodología “top-down”

Especificación de Requerimientos

Verificación

Diseño General

Diseño de Detalle

Implementación de Prototipos

Implementación Final

Test del Prototipo

Comportamiento TemporalModelo del Entorno

DescomposiciónAbstracción

MétodosFormales

Notación•Informal•Estructurada•Formal

10


19

SITR:Introducción

Lenguajes de programación

ü Lenguaje ensamblador:û Muy Eficiente

û Difícil de implementar la concurrencia.

ü Lenguajes secuenciales de alto nivelû C, C++, Java, Pascal, Fortran, Jovial, Coral, RTL/2û Portables, y fáciles de programarû No incorporan soporte para la concurrencia (debe ser soportado por el

S.O.)

ü Lenguajes concurrentes de alto nivelû ADA95, Modula-2, PEARL, Mesa, CHILLû Soprte de la concurrencia y especificaciones temporales en el propio

lenguaje

1. Introducción 1

2. Procesos 1

2.1. Definición y propiedades 1

2.2. Estados de un proceso 2

2.3. Información adicional sobre los procesos 3

2.4. Creación y terminación de procesos 4

i) Creación de Procesos 4

ii) Terminación de Procesos 5

3. Threads 5

3.1. Ventajas de Trabajar con Threads 7

3.2. Inconvenientes de Trabajar con Threads 7

3.3. Modelos de Control de Threads 7

i) A Nivel de Usuario 7

ii) A Nivel de Núcleo 8

iii) A Nivel Híbrido 9

Sistemas Informáticos en Tiempo Real Tema II

Tema II Procesos y Threads

1

1. Introducción.

Un sistema operativo potente (todos los Sistemas Operativos de Tiempo Real) es aquel capaz de ejercer más de una tarea en el mismo instante de tiempo, es decir, debe ser capaz de realizar tareas de forma concurrente. Por ejemplo, un sistema operativo multitarea debe ser capaz de ejecutar un programa del usuario al mismo tiempo que lee del disco o imprime un documento. Pueden existir varios mecanismos para conseguir que un Sistema Operativo cumpla esta característica. Nosotros explicaremos dos:

• PARALELISMO:

Se trata de un método para que un Sistema Operativo pueda realizar varias tareas haciendo uso de varios computadores. Los ordenadores se conectan entre sí de modo que cada uno puede estar realizando una tarea totalmente distinta a las que se ejecutan por los otros ordenadores, es decir, cada computador realiza una tarea.

• PSEUDOPARALELISMO:

A partir de un único computador o procesador es posible ejecutar tareas simultáneamente. En cada instante de tiempo sólo se realiza una tarea (en períodos muy pequeños), pero cuando transcurre un cierto tiempo puede haberse ejecutado parte de diversos programas dando la sensación de paralelismo. 2. Procesos. 2.1. Definición y Propiedades. Se puede definir como un programa que ha sido almacenado en la memoria del computador y cuya existencia es conocida por el Sistema Operativo. ¿Cómo se crea un proceso? Cuando el sistema operativo ejecuta un programa, éste realiza una copia del código ejecutable y la almacena en la memoria del computador (a partir de ese instante el programa pasa a ser un proceso). Además del código ejecutable, el proceso consta de otra información adicional:

- Pila de proceso que contiene datos temporales. - Sección de datos con variables globales. - Datos sobre planificación de los procesos.



2

Para que un proceso pueda ser gestionado de forma adecuada, éste debe disponer de la anterior información adicional además del código ejecutable.

Una diferencia entre programa y un proceso es que son una entidad pasiva y una activa, respectivamente. Es decir, mientras que un proceso experimenta cambios de estado, un programa es una entidad pasiva de cara al sistema operativo. 2.2. Estados de un Proceso. En cada instante, un proceso tiene asociado un estado que determinará la actividad de dicho proceso dentro del sistema operativo. Existen tres distintos:

• PREPARADO: El proceso está esperando que se le asigne un procesador para poder ejecutarse.

• EN EJECUCIÓN: El proceso es “dueño” de un procesador y sus

instrucciones se están ejecutando.

• SUSPENDIDO: El proceso está esperando que suceda algún evento como, por ejemplo, una operación de E/S.

Con respecto al estado de suspendido podemos decir que, a veces, un

proceso debe quedar suspendido para no degradar el rendimiento del sistema, es decir, si el proceso necesita la aparición de un evento para continuar ejecutándose, éste pasa a estado suspendido y así permitir que el procesador quede libre hasta que ocurra dicho evento (entonces, el proceso pasa a estado preparado).

NUEVO

PREPARADO EN EJECUCIÓN

Elegido Por el Planificador

expulsión

SUSPENDIDO

Esperar evento o E/S Fin del evento

o de E/S

TERMINADO

Admitido ACTIVO

Figura 2.1. Transiciones entre estados de un proceso



3

Veamos un ejemplo de vida de un proceso. Cuando llega un nuevo proceso, éste pasa a estado preparado de forma inmediata. En ese instante pueden suceder dos cosas:

a) Si no existe ningún procesador libre, el proceso permanece en estado preparado.

b) Si existe un procesador libre, el proceso pasa a ejecución. Una vez el proceso se está ejecutando y es “dueño” del procesador,

pueden suceder dos cosas: a) Si no existen procesos en estado preparado, éste permanece en

ejecución. b) Si existe otro proceso, el sistema operativo puede decidir conmutar

sus estados, es decir, el que está en ejecución deja libre el procesador pasando a estado preparado y el que está en preparado se hace dueño del computador y ejecuta su código.

El planificador de procesos es un constituyente del sistema operativo encargado de realizar la planificación (es decir, es el planificador el que decide cual debe ser el estado de un proceso en todo momento). Es una tarea de las más críticas puesto que determina el rendimiento, en gran medida, del sistema. 2.3. Información Adicional Sobre Procesos. La tabla de procesos es donde se almacena la información adicional de cada proceso que va a ser gestionada por el sistema operativo. El registro de cada proceso contiene información adicional sobre él mismo como:

• Contador de programa: Indicará la dirección de la siguiente

instrucción que el proceso ejecutará. • Estado del proceso: preparado, en ejecución o suspendido.

• Registros de la CPU: los acumuladores, apuntadores a pila y registros

de propósito general. Esta información está junto al C.P. por si se produce un error para permitir que el proceso continúe.

• Información de planificación: Aquí se incluye la prioridad del proceso

y otros parámetros de planificación.

• Información contable: tiempo utilizado, límites de tiempo, número de proceso...

• Información de estado de E/S: Almacena las solicitudes, los

dispositivos asignados, lista de archivos abiertos...



4

En resumen, en la tabla de procesos se guardará toda la información

necesaria para poder reanudar la ejecución de un proceso (como si nunca hubiera parado) después de cambiar de estado, conocido, como cambio de contexto. El encargado de acceder a cada uno de estos registros llamados Process Control Block (PCB) es el planificador. 2.4. Creación y Terminación de Procesos. Puesto que el sistema operativo ha de ser potente hemos de ejecutar procesos de forma concurrente y por ello necesitamos crear un método de creación y terminación dinámica de procesos.

i) Creación de Procesos.

Durante la ejecución de un proceso (denominado proceso padre) éste puede crear varios procesos nuevos (denominados procesos hijo) con una llamada al sistema. Esta llamada al sistema se puede realizar usando funciones de C para así solicitar la creación de nuevos procesos. Una vez creado un proceso hijo, el padre podrá continuar su ejecución de dos formas distintas:

• Continuar ejecutándose concurrentemente con sus hijos.

• Esperar a que los procesos hijos terminen.

Un subproceso puede obtener sus recursos directamente del sistema o puede estar restringido a los recursos del proceso padre, que debe compartir algunos con sus hijos o dividirlos entre sus hijos. Restringiendo a los hijos, el proceso padre evita la saturación del sistema por la creación de demasiados subprocesos. En el momento de creación el proceso padre puede transferir datos iniciales a su hijo.

Ejemplo de creación de procesos. En UNIX, un proceso nuevo se crea utilizando la llamada fork() duplicando el proceso padre en memoria. La diferencia entre padre e hijo es que el código de retorno del hijo es cero, mientras que el del padre es el identificador de proceso del hijo. Posteriormente, mediante una llamada al sistema se pone a ejecutar el proceso hijo. En UNIX, el proceso padre por excelencia es INIT ya que todos los hijos salen de él. A estos procesos hijos se conocen como SHELL. Esta filosofía de UNIX permite la creación de procesos hijos de forma dinámica.

PLANIFICADOR

0 PCB

1 PCB

2 PCB

n-1 PCB

n-2 PCB ……… n-3

PCB

Figura 2.2. Representación de una tabla de procesos



5

Supongamos un caso de ejemplo en el cual el proceso padre tiene que atender peticiones de servir una web. Para atenderla el proceso padre crea un nuevo proceso que la atenderá y después se eliminará.

ii) Terminación de Procesos.

La terminación se da cuando concluye la ejecución de su última línea y el propio proceso solicita eliminarse. No obstante existen otras circunstancias en las cuales se puede dar la terminación como, por ejemplo, a través de una llamada al sistema (como la llamada Kill()), un proceso puede provocar la terminación del otro. Por lo general, el proceso padre es el único que puede terminarlos y cuando esto ocurre puede almacenar datos provenientes del proceso hijo que ha terminado. Ejemplo de terminación de procesos. Cuando un padre elimina a su hijo se hace mediante la llamada exit() que devuelve el identificador de proceso del hijo, de forma que el padre puede distinguir cual de sus hijos a terminado. 3. Threads. Lo que se va a estudiar ahora es el mecanismo que permite refinar mucho más el concepto de concurrencia y paralelismo. Nosotros podemos subdividir un proceso (que es como una “tarea gorda”) en las tareas que lo componen pudiendo simplificarlo en hilos de ejecución. Los hilos de ejecución son las instrucciones que se ejecutan ininterrumpidamente. Los threads son estas instrucciones que se ejecutan secuencialmente y que componen el proceso.

Petición web

INIT

SHELL SHELL SHELL SHELL

SHELL

Figura 2.3. Política de creación de procesos en UNIX

Petición web Petición web Petición web Petición web



6

Desde el punto de vista del programa, la secuencia de instrucciones de un hilo de ejecución es un flujo ininterrumpido. En cambio, desde el punto de vista del sistema operativo, los hilos de ejecución no los detecta. Es como si fueran en el “paquete” junto con los procesos y no hubiera que “darlos de alta”. Por lo tanto, el sistema operativo no tiene nada que ver con los threads ni con su planificación.

Digamos que los threads son como una evolución del concepto del

proceso puesto que, al no necesitar ningún sistema de comunicación entre ellos, el intercambio de información es trivial y rápido. Además, estos no son controlados por el sistema operativo dándoles una mayor libertad de ejecución. De esto podemos decir que la utilización de threads proporciona una estructura fiable de programación, aumenta la productividad y el tiempo de respuesta. Características básicas.

- Comparten tanto el código como los datos. - Se evita el cambio de contexto, en gran medida. - El sistema operativo no es consciente de su existencia. Emplear threads tiene mucha importancia puesto que se consigue una

mejora del rendimiento del sistema al minimizar el tiempo perdido durante el cambio de contexto:

Cuando se conmuta, por ejemplo, entre el estado de preparado y el de ejecución hemos de almacenar toda la información relacionada con la ejecución del proceso en el PCB. Esto provoca que el computador emplee un tiempo que va a ser inútil. Con los threads el tiempo que tarda en realizarse un cambio de contexto es mínimo. Cuanto más grande es el periodo de tiempo de cambio de contexto mayor será la degradación de la efectividad del sistema.

P1 P1

Hilos de ejecución

Datos

T T

Hilos

Texto

Figura 2.4. Hilos de ejecución en el interior de dos procesos P1 y P2

Figura 2.5. Ejecución de una tarea



7

3.1. Ventajas de Trabajar con Threads. Obviando la complejidad de programación de los threads, éstos aportan muchas más ventajas que los procesos. Estas son las siguientes:

• Aumento del rendimiento del paralelismo. Si ejecutamos diferentes threads sobre procesadores diferentes

conseguiremos aumentar el rendimiento del sistema, eso si aprovechamos el paralelismo del hardware.

• Aumento de productividad. Puesto que utilizando los threads conseguiremos disminuir el tiempo

inútil de cambio de contexto, lo que obtenemos es que nuestro sistema sea más efectivo y trabaje más.

• Disminución del tiempo de respuesta. Ya que los threads comparten información y datos, el tiempo de cambio

de contexto es más pequeño pudiendo así terminar las tareas antes y dar una respuesta más rápida.

• Uso más eficiente de los recursos del sistema. Al utilizar threads en vez de procesos no nos hace falta la estructura de

datos completa que le hace falta al sistema para gestionar los procesos, sino que con menos información los threads pueden ser gestionados aprovechando más los recursos del sistema. Es más rentable y rápido de crear. 3.2. Inconvenientes de Trabajar con Threads.

• Mayor complejidad de programación. • No todos los programas se pueden implementar con threads. • La conversión de antiguos programas a su equivalente con threads no

es una tarea fácil. 3.3. Modelos de Control de Threads. Existen tres modelos tradicionales de control de threads:

i) Threads a Nivel de Usuario. Puesto que el sistema operativo donde se ejecutan no es capaz de

gestionarlos (es decir, el sistema operativo no tiene ninguna herramienta que los soporte), los programas que trabajan con éstos, generalmente se enlazan con unas bibliotecas (que traen definidas e implementadas funciones) que contienen todos los elementos necesarios para dicha gestión.



8

Este método tiene dos características importantes: • Los threads permanecen invisibles para el núcleo.

• Los threads compiten entre sí para adueñarse de los recursos

asignados el proceso al cual pertenecen. Aunque este tipo de threads tienen poco gasto, se puede observar que

tienen ciertas desventajas: • Si un thread queda en estado suspendido bloqueará el proceso a no

ser que exista otro thread especial que encargue de recuperar el control mediante una determinada llamada al sistema.

• No se puede aprovechar el paralelismo de un multiprocesador puesto

que si un procesador se la asigna a un proceso, los threads que lo componen no pueden ejecutarse en otro procesador.

ii) Threads a Nivel de Núcleo.

En este caso, son totalmente visibles por el núcleo y, además, son entidades planificadoras, es decir, el sistema operativo proporciona un conjunto de llamadas al sistema para manejarlos. Ahora los denominaremos procesos ligeros y éstos pueden competir por los recursos del sistema y para que no quede limitado al aprovechamiento del paralelismo. Como desventaja, el manejo de estos threads puede ser costoso al igual que el de procesos pesados aunque en operaciones de cambio de contexto y compartición de datos sean diez veces más rápidos.

Núcleo del Sistema Operativo

Soporte en ejecución del

lenguaje


lenguaje

Un programa, muchos hilos


= Espacio de direcciones = Construcción lingüística o hilo a nivel de usuario

= Proceso

Figura 2.6. Modelo del Thread a Nivel de Usuario



9

iii) Threads a Nivel Híbrido.

Este tipo de control ofrece ventajas de los de a nivel de usuario y los de a nivel de núcleo. El usuario escribe el programa en términos de hilos a nivel de usuario y después especifica cuantos threads son visibles para el núcleo y pueden, por tanto competir por los recursos del sistema sin verse limitados por los recursos del proceso al cual pertenecen. Los threads a nivel de usuario se llaman threads y los threads a nivel de núcleo se llaman procesos ligeros. Este es el sistema óptimo para un Sistema Informático de Tiempo Real ya que presenta los caracteres favorables de cada tipo.

u2 u1


Soporte en ejecución del lenguaje

= Proceso





lenguaje


lenguaje




= Proceso

Figura 2.7. Modelo de Thread a Nivel de Núcleo

Figura 2.8. Modelo de Thread Híbrido

1. Introducción 1

1.1. ¿Qué es POSIX? 1

1.2. Programación de Sistemas concurrentes 1

2. Llamadas al Sistema 2

3. Llamadas al Sistema para Gestión de Procesos 4

3.1. Llamada al Sistema fork() 4

3.2. Llamadas al Sistema getpid() y getpid() 6

3.3. Llamadas al Sistema wait() y waitpid() 7

3.4. Llamadas al Sistema exec() 7

3.5. Llamada al Sistema exit() 8

Resumen del tema III – Funciones POSIX 1

Resumen del tema III – Funciones POSIX 1

#include <sys/types.h> #include <sys/stat.h> #include <fcntl.h>

int open ( const char path, int oflag,…);

#include <sys/types.h> #include <unistd.h>

ssize_t write ( int fildes, const void buf, size_t nbytes); ssize_t read ( int fildes, const void buf, size_t nbytes);


pid_t fork ( void ); #include <sys/types.h> #include <unistd.h> uid_t getpid ( void ); uid_t getppid ( void ); #include <sys/types.h> #include <sys/wait.h> pid_t wait ( int *stat_loc); pid_t waitpid ( pid_t pid, int *stat_loc, int options); #include <unistd.h> int execl ( const char *path, const char *arg0, ..., const char *argn,

char /*NULL*/); int execle ( const char *path, const char *arg0, ..., const char *argn,

char /*NULL*/, char * const envp[]); int execlp ( const char *file, const char *arg0, ..., const char *argn,

char /*NULL*/); #include <uninst.h>

int execv ( const char *path, char const *argv[]); int execve ( const char *path, char const *argv[], char * const envp[]); int execvp ( const char *file, char const *argv[]);

#include <stdlib.h>

void exit ( int status);

Etiqueta Descripción S_IRUSR bit de permiso de lectura para el propietario

S_IWUSR bit de permiso de escritura para el propietario S_IXUSR bit de permiso de ejecución para el propietario

S_IRWXU lectura, escritura y ejecución para el propietario S_IRGRP bit de permiso de lectura para el grupo

S_IWGRP bit de permiso de escritura para el grupo S_IXGRP bit de permiso de ejecución para el grupo

S_IRWXG lectura, escritura y ejecución para el grupo

S_IROTH bit de permiso de lectura para otros S_IWOTH bit de permiso de lectura para otros

S_IXOTH bit de permiso de lectura para otros S_IRWXO lectura, escritura y ejecución para otros

S_ISUID fija el ID del usuario al momento de la ejecución

S_ISGID fija el ID del grupo al momento de la ejecución

Etiqueta Descripción O_RDONLY Abre el fichero en modo sólo escritura O_WRONLY Abre el fichero en modo sólo escritura O_RDWR Abre el fichero en modo lectura / escritura O_APPEND Abre el fichero en modo “añadir al final” O_CREAT Crea el fichero si no existe O_TTRUNC Abre el fichero existente y lo trunca a 0

Sistemas Informáticos en Tiempo Real Tema III

Tema III Funciones POSIX 1

1

1. Introducción. 1.1. ¿Qué es POSIX? En este tema estudiaremos las herramientas necesarias para programar sistemas concurrentes ya que todos los sistemas Informáticos de Tiempo Real cumplen esta propiedad. Debido a la necesidad de estandarizar los distintos sistemas UNIX (la diferencia de programación y la falta de portabilidad del código provoca estas diferencias a nivel de sistema entre los distintos sistemas operativos UNIX) la IEEE ha desarrollado un grupo de estándares: POSIX (Potable Operating System Interface). Este especifica la interfaz entre el sistema operativo y el usuario de modo que los usuarios podemos interactuar con el sistema operativo. Gracias a esta estandarización se permite que los programas de las diversas aplicaciones sean transportables entre distintas plataformas.

Estándar Descripción POSIX.1 Interfaz del sistema para programas de aplicación (API) en lenguaje C POSIX.1b Rectificación 1 del API: Extensión de tiempo real en C POSIX.1c Rectificación 2 del API: Extensión de hilos de control POSIX.2 Intérprete de comandos y útiles POSIX.4 Ahora llamado POSIX.1c POSIX.5 POSIX.1 lenguaje ADA POSIX.6 Seguridad POSIX.7 Administración del sistema

Tabla 3.1. Algunos estándares POSIX

1.2. Programación de Sistemas Concurrentes. Con respecto a la programación concurrente en UNIX podemos decir que se realiza de dos maneras:

• Mediante la implementación de programas en un lenguaje diseñado para dar soporte a la concurrencia como Java o Ada. La concurrencia la proporciona el lenguaje.

• Mediante la utilización del lenguaje (estándar bajo un sistema UNIX que

cumpla el estándar POSIX). La concurrencia, en este caso, la proporciona el sistema operativo. En UNIX, los procesos solicitan servicios al sistema utilizando llamadas al sistema (éstas son puntos de entrada directa al núcleo). El núcleo es una colección de programas muy eficaces que gobiernan el control del sistema operativo.

Aparte de las llamadas (que son parte intrínseca del núcleo) están

disponibles muchas funciones de la biblioteca que pueden o no hacer uso de llamadas al sistema.



2

2. Llamadas al Sistema. Son un conjunto de servicios básicos, proporcionados por el sistema operativo, que definen una vía de comunicación entre un proceso y el sistema operativo. Con interrupciones se consigue la implementación de las llamadas al sistema que en UNIX se clasifican en 5 categorías:

1. Llamadas al sistema para gestión de procesos. 2. Llamadas al sistema para gestión de señales. 3. Llamadas al sistema para gestión de memoria. 4. Llamadas al sistema para gestión de ficheros y directorios. 5. Llamadas al sistema para gestión de Entrada/Salida.

Veamos a continuación un ejemplo sencillo de la creación de un fichero (si este no existe) y en el cual se escribe la cadena “Esto es un ejemplo”:

Usando la llamada open() podemos abrir o crear un nuevo fichero. La sintaxis es:

donde el primer argumento es el nombre del fichero que se quiere abrir y el segundo indica el modo en que se va a abrir el fichero (estos modos se representan mediante etiquetas predefinidas en el fichero cabecera fcntl.h). Cabe decir que podemos utilizar el operador lógico OR para obtener un efecto combinado.

En el caso de que se vaya a

crear un fichero, los puntos suspensivos se sustituyen por un tercer parámetro de tipo mode_t que especifica los permisos del fichero que se va a crear.

Tabla 3.2. Modos de apertura de un fichero

Figura 3.2. Patrón de la máscara de permisos

Etiqueta Descripción O_RDONLY Abre el fichero en modo sólo escritura O_WRONLY Abre el fichero en modo sólo escritura O_RDWR Abre el fichero en modo lectura / escritura O_APPEND Abre el fichero en modo “añadir al final” O_CREAT Crea el fichero si no existe O_TTRUNC Abre el fichero existente y lo trunca a 0

#include <sys/types.h> #include <sys/stat.h> #include <fcntl.h>

int open ( const char path, int oflag,…);

Programas de usuario (procesos)

Interfaz de llamadas al sistema

Kernel

Hardware (Recursos)

Figura 3.1. Llamadas al sistema

Usuario

r

Grupo Otro s

Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0

r

r

w

w

w

x

x

x



3

Los archivos pueden ser

empleados por: un usuario, un grupo o el resto. Los permisos de cada una de estas clases son: leer (r), escribir (w) y ejecutar (x). Cada fichero tiene asociados 9 bits donde cada BIT a 0 o a 1 quita o da el permiso correspondiente.

Con respecto a dos operaciones básicas con ficheros: leer y escribir, podemos decir que se utilizan a través

de las llamadas al sistema read() y write(). La llamada read() y write() tiene la siguiente definición:

Esta llamada intenta escribir (respectivamente leer) nbytes bytes tomados del buffer buf en el archivo cuyo descriptor es fildes. Si esta llamada tiene éxito entonces devuelve el número de bytes escritos. El ejemplo sería el siguiente:

Etiqueta Descripción S_IRUSR bit de permiso de lectura para el propietario

S_IWUSR bit de permiso de escritura para el propietario S_IXUSR bit de permiso de ejecución para el propietario

S_IRWXU lectura, escritura y ejecución para el propietario

S_IRGRP bit de permiso de lectura para el grupo S_IWGRP bit de permiso de escritura para el grupo

S_IXGRP bit de permiso de ejecución para el grupo S_IRWXG lectura, escritura y ejecución para el grupo

S_IROTH bit de permiso de lectura para otros S_IWOTH bit de permiso de lectura para otros

S_IXOTH bit de permiso de lectura para otros

S_IRWXO lectura, escritura y ejecución para otros S_ISUID fija el ID del usuario al momento de la ejecución

S_ISGID fija el ID del grupo al momento de la ejecución


ssize_t write ( int fildes, const void buf, size_t nbytes); ssize_t read ( int fildes, const void buf, size_t nbytes);

#include <sys/types.h> #include <sys/stat.h> #include <unistd.h> #include <fcntl.h> #include <stdio.h> #include <string.h> #define BLKSIZE 100 void main ( void ) {

int fd, bytes_escritos, bytes_leidos; /*descriptor de fichero*/ char buffer[BLKSIZE]; mode_t modo = S_IRWXU; /* modo de r, w y x para el propietario*/ strcpy(buffer, "Esto es un ejemplo\n"); if ((fd = open ("ejemplo", O_RDWR | O_CREAT, modo))== -1)

/*abre el fichero ejemplo en modo lectura/escritura o lo crea si no existe */

perror ("Error al abrir o crear el fichero"); /*muestra un error si no puede abrir/crear el fiche ro*/

else {

bytes_escritos = write(fd, buffer, strlen(buffer)); /* escribe buffer de tamaño sizeof(buffer) en fd */ bytes_leidos = read(fd, buffer, BLKSIZE); buffer[bytes_leidos]='\0'; printf("%s son %d \n", buffer, bytes_leidos);

} exit(0); }

Tabla 3.3. Etiquetas de permisos de un fichero



4

3. Llamadas al Sistema para Gestión de Procesos. 3.1. Llamada al Sistema fork(). La función fork() permite la creación de un nuevo proceso, que es una copia exacta (un doble con un nuevo identificador pero con el mismo código). Una vez creado el hijo, éste comienza su ejecución en la línea siguiente a la última llamada a la función fork(), es decir, a partir de cuando fue creado. La sintaxis es:

Se puede observar que no tiene ningún parámetro y devuelve un entero. fork() devuelve el identificador de procesos del nuevo proceso creado al proceso padre y devuelve un cero al hijo. Si en un programa escribo la función fork(), no tengo que pasarle ningún parámetro, pues se supone que el proceso hijo creado es del proceso o programa que estamos escribiendo. El proceso hijo se empieza a ejecutar a partir de la línea donde se a realizado la llamada fork().

El ejemplo se puede expresar gráficamente como:

#include <sys/types.h> #include <unistd.h> pid_t fork ( void );

#include <sys/types.h> #include <unistd.h> #include <stdio.h> void main ( void ) {

int pid; pid = fork(); switch (pid) {

case -1: perror ("No se ha podido crear el hijo"); break ; case 0: printf("Soy el hijo, mi PID es %d y mi PPID es

%d\n", getpid(), getppid()); break ; default : printf ("Soy el padre, mi PID es %d y el PID de

mi hijo es %d\n", getpid(), pid); } exit(0);

}

………………………………………………………………………

fork ()

………………………………………………………………………

fork ()

………………………………………………………………………

………………………………………………………………………

Comienza su ejecución después del fork ()

Este fragmento de código no es ejecutado

Este fragmento de código si es ejecutado

PADRE

HIJO

Figura 3.3. Uso de la función fork ()



5

El proceso hijo hereda del padre lo siguiente:

- Con qué permisos se crean los ficheros. - Variables de entorno y argumentos, es decir, las condiciones en que

se va a ejecutar el proceso.

- Descriptores de fichero.

El proceso hijo difiere del padre en lo siguiente: - El proceso hijo tiene su propio identificador PID.

- El hijo tiene el identificador del padre PPID, de forma que sabemos

cual es su padre (Parent Process Identificator).

- Como los sistemas operativos UNIX tienen un contador que mide cuánto tiempo lleva un proceso ejecutándose, se inicializa la información de contabilidad del proceso hijo.

Los errores que pueden darse al ejecutar la llamada fork() son: - Saturación del sistema por sobrepasar el límite de procesos

permitidos.

- Excedente de procesos máximos para un usuario.

- Insuficiencia en la memoria.

Si la función fork() devuelve un –1 esto significa que no se ha podido crear un hijo. Con respecto a la ejecución del fork() en un proceso, es necesario realizar una aclaración. Al ejecutarla, se crea un hijo cuyo código es igual pero con el contador de programa señalando a la línea siguiente al fork() que lo ha creado.

Cuando se ejecuta la línea de código 5 (por ejemplo), donde está el fork(), se crea un hijo del proceso padre. En este momento, tenemos dos hilos de ejecución, es decir, de un programa ejecutándose, se pasa a leer dos (el mismo que ya estaba ejecutándose y un programa hijo, que se ejecuta a partir de la línea que lo creó). Por tanto, el proceso P2 comienza a ejecutarse en la línea posterior al fork() que lo ha creado. Ahora tengo dos programas que se están ejecutando en un determinado orden, que ya veremos (primero P1 y luego P2, a la vez, primero P2 y luego P1,...). Supongamos que van ejecutándose a la vez.



6

El proceso P1 tiene en la siguiente línea de código otro fork(), por lo que

vuelve a crear otro hijo suyo, que se ejecutará a partir de la línea siguiente. Al mismo tiempo, el proceso P2 tiene en la línea que empieza a ejecutar un fork(), por lo que crea un hijo suyo que se empezará a ejecutar a partir de ese fork() que lo ha creado. En total, se han creado 3 hijos, y de 1 programa en ejecución o proceso que teníamos al principio, tenemos ahora 4 procesos ejecutándose en el orden en que determine el planificador. 3.2. Llamadas al Sistema getpid() y getppid(). Ambas se definen de la siguiente forma:

Con estas llamadas obtenemos las PID’s del proceso que la invoca y de

su proceso padre respectivamente. El tipo uid_t es un entero predefinido en <sys/types.h>.

#include <stdio.h> int main (void) { …………………………………………………………………………………………………… pid1 = fork ( ); pid2 = fork ( ); …………………………………………………………………………………………………… }

#include <stdio.h> int main (void) { …………………………………………………………………………………………………… pid1 = fork ( ); pid2 = fork ( ); ……………………………………………………………………………………………………}

#include <stdio.h> int main (void) { …………………………………………………………………………………………………… pid1 = fork ( ); pid2 = fork ( ); …………………………………………………………………………………………………… }

#include <stdio.h> int main (void) { …………………………………………………………………………………………………… pid1 = fork ( ); pid2 = fork ( ); ……………………………………………………………………………………………………}

SE CREA UN HIJO DE P 1

SE

CR

EA

OT

RO

HIJO

DE

P1

P2

P3

P4

Las llaves indican el código ejecutado por cada proceso

Figura 3.4. Creación de procesos hijo

SE

CR

EA

UN

HIJO

DE

P2

#include <sys/types.h> #include <unistd.h> uid_t getpid ( void ); uid_t getppid ( void );

P1



7

3.3. Llamada al Sistema wait() y waitpid(). Si un padre desea esperar hasta que el proceso hijo termine de ejecutarse, éste debe realizar la llamada al sistema wait o waitpid que se definen como sigue:

La llamada wait() suspende la ejecución del proceso que lo invoca hasta

que finaliza alguno de sus hijos. Si el padre ejecuta esta llamada, se le notifica la terminación y el código de terminación del proceso hijo. Si el padre no está ejecutando wait() y termina, entonces no espera a que su proceso hijo termine. Por tanto, la conexión entre el proceso hijo y su padre desaparece y el proceso hijo sigue ejecutándose sin que se entere el padre. 3.4. Llamada al Sistema exec().

La familia de llamadas exec() cambia la imagen de memoria de un proceso por el contenido de un fichero ejecutable. La forma habitual de utilizar la combinación fork/exec es dejar que el hijo ejecute exec() mientras el padre continua la ejecución normal. Existen 6 variaciones de exec() que se distinguen por la forma en que son pasados los argumentos de la línea de comandos y el entorno que utilizan. Las seis variaciones se pueden agrupar en dos grupos:

• Llamadas execl: execl(), execlp(), execle().

Las llamadas execl (execl(), execlp(), execle()) pasan los argumentos de la línea de comandos del programa mediante una lista. Son útiles si se conoce el número de argumentos que se van a pasar

execle() permite pasar nuevos valores de variables de entorno. execlp() permite tomar el path por defecto del entorno.

#include <sys/types.h> #include <sys/wait.h> pid_t wait ( int *stat_loc); pid_t waitpid ( pid_t pid, int *stat_loc, int options);

#include <unistd.h>

int execl ( const char *path, const char *arg0, ..., const char *argn, char /*NULL*/);

int execle ( const char *path, const char *arg0, ..., const char *argn, char /*NULL*/, char * const envp[]);

int execlp ( const char *file, const char *arg0, ..., const char *argn, char /*NULL*/);



8

• Llamadas execv: execv(), execvp(), execve(). Pasan los argumentos de la linea de comando en un array de argumentos.

execve() permite pasar nuevos valores de variables de entorno. execvp() permite tomar el path por defecto del entorno.

3.5. Llamada al Sistema exit().

Fuerza la terminación de un proceso devolviendo un código de error. Está implícita en la terminación de todos los procesos. Al finalizar un proceso se recuperan todos los recursos asignados al proceso.

Si el padre del proceso que termina está ejecutando wait() se le notifica la terminación y el código de terminación sólo cuando termine de realizar dicha espera. Si el padre no ejecuta wait() el proceso se transforma en un proceso zombie huérfano hasta que es adoptado por INIT. La sintaxis sería la siguiente:

El campo status se emplea para imprimir un mensaje de error por

pantalla si ha ocurrido un error, ya que el valor de status indicará el mensaje que saldrá por pantalla.

#include <stdlib.h> void exit ( int status);

#include <uninst.h>

int execv ( const char *path, char const *argv[]); int execve ( const char *path, char const *argv[], char * const

envp[]); int execvp ( const char *file, char const *argv[]);

?1

Sistemas Informáticos de Tiempo RealISA-UMH © T-99-001V1.0

1

FuncionesPOSIX (I)

Funciones POSIX (I): Introducción

? ¿Que es POSIX?? POSIX: Portable Operating System Interface (IEEE)

? Especifica la interfaz entre el sistema y el usuario.

? Intenta estandarizar los interfaces de los SO para permitir que las aplicaciones funcionen en distintas plataformas.

? POSIX se compone de distintas normas estándares llamadas “miembros”

Estándar DescripciónPOSIX.1 Interfaz del sistema para programas de aplicación (API) en lenguaje CPOSIX.1b Rectificación 1 del API: Extensión de tiempo real en CPOSIX.1c Rectificación 2 del API: Extensión de hilos de controlPOSIX.2 Intérprete de comandos y útilesPOSIX.4 Ahora llamado POSIX.1cPOSIX.5 POSIX.1 Lenguaje ADAPOSIX.6 SeguridadPOSIX.7 Administración del sistema


2

FuncionesPOSIX (I)

Programación de Sistemas Concurrentes

? La programación concurrente se puede realizar de dos formas

? Utilizando un lenguaje diseñado para soportar concurrencia

• La concurrencia la proporciona el lenguaje• ADA• JAVA

? Utilizando C estándar bajo un sistema UNIX que cumpla POSIX

• La concurrencia la proporciona el SO• Los procesos solicitan servicios al SO (p.e. de E/S) mediante llamadas al sistema

?2


3

FuncionesPOSIX (I)

Llamadas al Sistema (I)

? Las llamadas al sistema son un conjunto de servicios básicos del SO? Definen la interfaz entre un proceso y el SO? Son una parte intrínseca del núcleo del SO (Kernel)? Kernel: colección de módulos software que se ejecutan de forma

privilegiada (se tiene acceso a todos los recursos de la máquina)

Programas de usuario (procesos)

Interfaz de llamadas al sistema

Kernel

Hardware (Recursos)


4

FuncionesPOSIX (I)

Llamadas al Sistema (II)

? La implementación de las llamadas al sistema se realiza medianteinterrupciones software o traps

? Normalmente se proporciona al usuario una interfaz (funciones de biblioteca) que ocultan al usuario el mecanismo interno de las llamadas

? Tipos de llamadas en UNIX

? Llamadas al sistema para gestión de procesos

? Llamadas al sistema para gestión de señales

? Llamadas al sistema para gestión de memoria

? Llamadas al sistema para gestión de ficheros y directorios

? Llamadas al sistema para gestión de E/S

?3


5

FuncionesPOSIX (I)

Llamadas al sistema: Ejemplo (I)

? Ejemplo de utilización de llamadas al sistema: Crear un fichero “ejemplo” (si no existe) y escribir la cadena “Esto es un ejemplo” en él

? Llamadas involucradas: open, write? open: asocia un descriptor de fichero con un fichero o dispositivo lógico.

#include <sys/types.h>#include <sys/stat.h>#include <fcntl.h>

int open (const char *path,int oflag, ...);

Etiqueta DescripciónO_RDONLY Abre el fichero en modo sólo lecturaO_WRONLY Abre el fichero en modo sólo escrituraO_RDWR Abre el fichero en modo lectura / escrituraO_APPEND Abre el fichero en modo “añadir al final”O_CREAT Crea el fichero si no existeO_TRUNC Abre el fichero existente y lo trunca a 0

Modos de apertura de ficheros


6

FuncionesPOSIX (I)

Llamadas al sistema: Ejemplo (II)

? En caso de crear el fichero es necesario especificar el modo de apertura (permisos)

? Permisos en UNIX? Cada fichero en UNIX tiene permisos para el propietario del mismo, para el

grupo de usuarios del propietario y para el resto? Los permisos para cada una de las clases anteriores son: leer (R), escribir

(w) y ejecutar (X).? Cada fichero tiene asociados 9 bits donde cada bit a 1 o a 0 da o quita el

permiso correspondiente según el patrón que se muestra a continuación

Usuario Grupo Otros

r w x r w x r w x

Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0

Patrón de la máscara de permisos

?4


7

FuncionesPOSIX (I)

Llamadas al sistema: Ejemplo (III)

? En vez de utilizar el valor numérico obtenido mediante la combinación de bits se pueden utilizar las siguientes etiquetas:

Etiqueta DescripciónS_IRUSR bit de permiso de lectura para el propietarioS_IWUSR bit de permiso de escritura para el propietarioS_IXUSR bit de permiso de ejecución para el propietarioS_IRWXU lectura, escritura y ejecución para el propietarioS_IRGRP bit de permiso de lectura para el grupoS_IWGRP bit de permiso de escritura para el grupoS_IXGRP bit de permiso de ejecución para el grupoS_IRWXG lectura, escritura y ejecución para el grupoS_IROTH bit de permiso de lectura para otrosS_IWOTH bit de permiso de lectura para otrosS_IXOTH bit de permiso de lectura para otrosS_IRWXO lectura, escritura y ejecución para otrosS_ISUID fija el ID del usuario al momento de la ejecuciónS_ISGID fija el ID del grupo al momento de la ejecución

Etiquetas de permisos de un fichero


8

FuncionesPOSIX (I)

Llamadas al sistema: Ejemplo (IV)

? Las etiquetas de permisos se pueden combinar mediante el operador “||” (“o” lógico)

fd = open (“ejemplo”, O_CREAT, S_IRWXU || S_IXGRP);

? Llamada write: intenta escribir nbytes tomados del buffer buf en el archivo con descriptor fildes

? Devuelve el número de bytes leídos

#include <unistd.h>ssize_t write(int fildes, const void *buf, size_t nbytes);

?5


9

FuncionesPOSIX (I)

Llamadas al sistema: Ejemplo (V)

#include <sys/types.h>#include <sys/stat.h>#include <unistd.h>#include <fcntl.h>#include <stdio.h>#include <string.h>void main (void){int fd, bytes_escritos; /*descriptor de fichero*/char buffer[100];mode_t modo = S_IRWXU; /* modo de r, w y x para el propietario*/strcpy(buffer, "Esto es un ejemplo\n");if ((fd = open ("ejemplo", O_RDWR | O_CREAT, modo))== -1)

/*abre el fichero ejemplo en modo lectura/escritura o locrea si no existe */

perror ("Error al abrir o crear el fichero");/*muestra un mensaje de error si no puede abrir/crear el fichero*/

elsebytes_escritos = write(fd, buffer, strlen(buffer));/* escribe buffer de tama¤o sizeof(buffer) en fd */

exit(0);}


10

FuncionesPOSIX (I)

Llamadas al sistema: Ejemplo (VI)

? Análogamente se puede leer el contenido del fichero “ejemplo” de la siguiente forma

#include <sys/types.h>#include <sys/stat.h>#include <unistd.h>#include <fcntl.h>#include <stdio.h> #define BLKSIZE 100 /*tamaño del buffer*/void main(void){int fd, bytes_read;char buffer[BLKSIZE];if ((fd = open("ejemplo", O_RDWR))==-1)

perror("Error al abrir elfichero");else{

bytes_read = read(fd,buffer, BLKSIZE);buffer[bytes_read]='\0';printf("%s son %d \n", buffer,bytes_read);

}exit(0);

}

?6


11

FuncionesPOSIX (I)

Gestión de Procesos en POSIX

Llamada Funciónfork Crea un procesogetpid Obtiene el identificador del procesogetppid Obtiene el identificador del proceso padrewait Detiene un proceso hasta que alguno de sus hijos terminawaitpid Detiene un proceso hasta que un determinado hijo

terminaexec (Conjunto de llamadas) Cambia la imagen de memoria de

un procesoexit Fuerza la terminación del proceso que la invoca


12

FuncionesPOSIX (I)

Llamada al sistema fork (I)

? Provoca la creación de un nuevo proceso? El nuevo proceso hijo es una copia exacta del padre? Sintaxis

? Devuelve 0 al proceso hijo y el PID del hijo al padre

? El proceso hijo hereda del padre los siguientes atributos? UID (identificador de usuario) y GID (identificador de grupo)? Variables de entorno y argumentos? Descriptores de ficheros? Directorio de trabajo actual y raíz? Máscara de modo de creación de ficheros.

#include <sys/types>#include <unistd.h>

pid_t fork(void);

?7


13

FuncionesPOSIX (I)

Llamada al sistema fork (II)

? El proceso difiere del padre en los siguientes atributos

? El proceso hijo tiene su propio identificador PID

? El hijo tiene su propio PPID (Parent Process ID)

? Se inicializa la información de contabilidad del proceso hijo

? Errores posibles al ejecutar fork

? Se excede el número máximo de procesos permitido en el sistema

? Se excede el número de procesos máximo permitido a un usuario

? Memoria insuficiente


14

FuncionesPOSIX (I)

Llamadas al sistema getpid y getppid

? getpid: Obtiene el PID del proceso que la invoca? getppid: Obtiene el PID del padre del proceso que la invoca

? Sintaxis:

? El tipo uid_t no es más que un entero definido en types.h

#include <sys/types.h>#include <unistd.h>

uid_t getpid (void);uid_t getppid (void);

?8


15

FuncionesPOSIX (I)

Llamada al sistema exit

? Fuerza la terminación de un proceso devolviendo un código de error? Está implícita en la terminación de todos los procesos

? Al finalizar un proceso se recuperan todos los recursos asignados al proceso

? Si el padre del proceso que termina está ejecutando wait se le notifica la terminación y el código de terminación

? Si el padre no ejecuta wait el proceso se transforma en un proceso zombie huérfano hasta que es adoptado por init

#include <stdlib.h>

void exit(int status);


16

FuncionesPOSIX (I)

Llamada al sistema fork: Ejemplo

#include <sys/types.h>#include <unistd.h>#include <stdio.h>

void main (void){int pid;pid = fork();switch (pid){

case -1: perror ("No se ha podido crear el hijo");break;

case 0: printf("Soy el hijo, mi PID es %d y mi PPID es %d\n",getpid(), getppid());

break;

default: printf ("Soy el padre, mi PID es %d y el PID de mihijo es %d\n", getpid(), pid);

}exit(0);

}

?9


17

FuncionesPOSIX (I)

Llamada al sistema wait

? wait suspende la ejecución del proceso que la llama hasta que finaliza alguno de sus hijos (devuelve el PID del hijo)

? En caso de error (el proceso no tiene hijos o estos ya han terminado) devuelve 1

? stat_loc es un puntero a un entero. Si es distinto de NULL en la llamada,en él se guarda el estado devuelto por el hijo.

? waitpid proporciona métodos más flexible y potentes para esperar a los hijos (se puede esperar a uno en particular)

#include <sys/types.h>#include >sys/wait.h>

pid_t wait(int *stat_loc)pid_t waitpid(pid_t pid, int *stat_loc, int options);


18

FuncionesPOSIX (I)

Llamada al sistema wait : Ejemplo

#include <sys/types.h>#include <sys/wait.h>void main(void){pid_t childpid, childdead;int i;if ((childpid = fork()) == -1){

perror("fork no pudo crear el hijo");exit(1);

}else if (childpid == 0)

{printf ("Soy el hijo y voy a contar hasta 100000 \n");for (i=0;i<100000; i++) {}

}else {printf("Soy el padre y voy a esperar a mi hijo\n");if ((childdead = wait(0))==-1)

perror("no he podido esperar al hijo");else

printf("Mi hijo con pid %d , ha muerto\n",childdead);}

exit(0);}

?10


19

FuncionesPOSIX (I)

Familia de llamadas al sistema exec

? La familia de llamadas exec cambia la imagen de memoria de un proceso por el contenido de un fichero ejecutable

? La forma habitual de utlizar la combinación fork/exec es dejar que el hijo ejecute exec mientras el padre continua la ejecución normal

? Existen 6 variaciones de exec que se distinguen por la forma en que son pasados los argumentos de la línea de comandos y el entorno que utilizan.

? Las seis variaciones se pueden agrupar en dos grupos

? Llamadas execl : execl, execlp execle? Llamadas execv: execv, execvp, execve


20

FuncionesPOSIX (I)

Llamadas execl

? Las llamadas execl (execl, execlp, execle) pasan los argumentos de la linea de comando del programa mediante una lista.

? Son útiles si se conoce el número de argumentos que se van a a pasar

? execle permite pasar nuevos valores de variables de entorno? execlp permite tomar el path por defecto del entorno

#include <uninst.h>

int execl (const char *path, const char *arg0, ...,const char argn, char /*NULL*/);

int execle (const char *path, const char *arg0, ...,const char argn, char /*NULL*/, char*const envp[]);

int execlp (const char *file, const char *arg0, ...,const char argn, char /*NULL*/);

?11


21

FuncionesPOSIX (I)

Llamadas execv

? Pasan los argumentos de la linea de comando en un array de argumentos

? execve permite pasar nuevos valores de variables de entorno? execvp permite tomar el path por defecto del entorno

#include <uninst.h>

int execv (const char *path, char const *argv[]);int execve (const char *path, char const *argv[],

char *const envp[]);int execv (const char *file, char const *argv[]);


22

FuncionesPOSIX (I)

Llamada execl : Ejemplo (I)

#include <sys/types.h>#include <unistd.h>#include <stdio.h>#include <errno.h>

void main (void){pid_t childpid;if ((childpid =fork()) ==1)

{perror("Error al crear el hijo");exit(1);

}else if (childpid ==0)

{printf("Soy el hijo y voy a ejecutar ls -l\n");if (execl("/bin/ls", "ls", "-l", NULL) <0){perror("Error al ejecutar ls\n");exit (1);

}}else{

printf("Soy el padre y termino\n");exit(0);

}}

?12


23

FuncionesPOSIX (I)

Llamada execv : Ejemplo (II)

#include <sys/types.h>#include <unistd.h>#include <stdio.h>#include <errno.h>

void main (int argc, char *argv[]){pid_t childpid;if ((childpid =fork()) ==1){

perror("Error al crear el hijo");exit(1);

}else if (childpid ==0)

{printf("Soy el hijo y voy a ejecutar el comando %s/n",argv[1]);if (execvp(argv[1], &argv[1]) <0){perror("Error al ejecutar el comando");exit (1);

}}else{

printf("Soy el padre y termino\n");exit(0);

}}

1. Introducción 1

2. Planificación 2

2.1. Colas de Planificación 2

2.2. Planificación de Procesos 3

2.2.1. Objetivos de un Buen Planificador 3

2.2.2. Estructura de Planificación 4

2.2.3. El despachador 4

2.3. Algoritmos de Planificación 4

2.3.1. Criterios para Comparar Algoritmos de Planificación 4

2.3.2. Tipos de Algoritmos de Planificación 5

i) Servicio por orden de llegada 5

ii) Prioridad al trabajo más breve 6

iii) Prioridad al que le resta menos tiempo 6

iv) Planificación por prioridades 6

v) Planificación por Turno Rotatorio 7

vi) Planificación con clases de prioridades 8

vii) Planificación con múltiples colas realimentadas 9

Resumen del tema IV – Conceptos de Planificación

Resumen del tema IV – Conceptos de Planificación

El objetivo de la multiprogramación es que en todo momento se ejecute un proceso para maximizar el uso de la CPU.

La planificación es el criterio que se sigue a la hora de decidir qué proceso debe entrar en ejecución.

Aumentaremos la cantidad de trabajo por unidad de tiempo gracias a la multiprogramación.

Las colas de planificación serán listas donde se enumerarán los PID’s de los procesos que están en cada estado.

En la cola de trabajos están incluidos todos los programas que esperan una asignación de memoria del computador.

Una vez listos para su ejecución y almacenados en la memoria principal éstos pasan a la cola de procesos listos.

La lista de procesos que esperan un dispositivo de E/S se denomina cola de dispositivos.

2.2. Planificación de Procesos.

El planificador se encarga de decidir que proceso se ejecuta.

El criterio que utiliza se llama algoritmo de planificación:

1. Equidad: Ha de asignarse el procesador a cada proceso con el mismo tiempo de utilización.

2. Eficiencia: El funcionamiento del procesador ha de aprovecharse al cien por cien.

3. Tiempo de respuesta: El tiempo de respuesta debe minimizarse al máximo.

4. Tiempo de proceso o espera: El tiempo de espera de los usuarios ha de minimizarse al máximo.

5. Productividad: Debe conseguirse maximizar el número de trabajos por unidad de tiempo.

¡algunos de estos objetivos son contradictorios! El dispacher es el módulo que realmente entrega el control de la CPU al proceso seleccionado por el planificador.

2.3.1. Tipos de Algoritmos de Planificación.

i) Servicio por orden de llegada (FCFS: “First Come, First Server”). �� convoy

ii) Prioridad al trabajo más breve (SJF: “Shortest Job First”). �� Asocia a cada tarea un tiempo � Se ejecuta el de menor tiempo � No existe expulsión

iii) Prioridad al que le resta menos tiempo (SRTF: “Shortest Remaining Time First”). Inconvenientes:

• El intervalo de la CPU es difícil de predecir.

• Posibilidad de inanición: los trabajos largos no se ejecutarán mientras hayan trabajos cortos.

iv) Planificación por prioridades.

• Algoritmos con expulsión o sin expulsión.

• Prioridades estáticas o dinámicas:

Prioridades estáticas: En estos, la prioridad se asigna antes de la ejecución y no cambia. Esto

provoca, generalmente, la aparición del problema de inanición.

Prioridades dinámicas: La prioridad cambia con el tiempo de modo que se soluciona el problema

de inanición. Actualización de prioridades.

v) Planificación por Turno Rotatorio.

A cada proceso se le asigna un quantum durante el cual el proceso puede ejecutarse. Si el proceso está

todavía en ejecución cuando el quantum termina, se le expulsa.

� Un valor muy pequeño al quantum aumenta demasiado el número de cambios de contexto.

� Un valor demasiado grande aumenta los tiempos de respuesta a peticiones cortas pudiendo llegar a

degenerar en un algoritmo FCFS.

vi) Planificación con clases de prioridades. Cola de procesos se divide en varias colas donde cada una posee su propio algoritmo de planificación.

vii) Planificación con múltiples colas realimentadas. Un proceso puede cambiar de cola de acuerdo a:

� Los procesos con un tiempo de espera acumulado elevado son promocionados.

� Los procesos con un tiempo de utilización de CPU elevado son degradados.

Sistemas Informáticos en Tiempo Real Tema IV

Tema IV Conceptos de Planificación

1

1. Introducción.

El objetivo de la multiprogramación es que en todo momento se ejecute un proceso para maximizar la utilización de la CPU. Nosotros conocemos que la planificación es el criterio que se sigue a la hora de decidir qué proceso debe entrar en ejecución. La tarea de planificación es quizá la más crítica dentro de un Sistema en Tiempo Real puesto que en este caso prima la rapidez en la ejecución de tareas.

Con la multiprogramación se pretende emplear productivamente el tiempo desperdiciado al no ejecutar ninguna tarea útil (como por ejemplo, en un sistema de computación sencillo, donde la CPU permanecerá inactiva en el momento cuando tuviese que esperar un evento externo). Gracias a la multiprogramación se consigue un aumento de la utilización de la CPU que conlleva a una mayor productividad. Es decir, aumentaremos la cantidad de trabajo por unidad de tiempo gracias a la multiprogramación.

Veamos un ejemplo en el cual tenemos dos procesos P1 y P2. Cada proceso se ejecuta durante un segundo y luego espera otro segundo: Si ejecutamos el proceso P1 y luego el proceso P2 de modo que cada proceso se ejecuta 30 veces se tiene que

Figura 4.1. Ejecución de procesos sin multiprogramación

Se puede observar que cada uno de los procesos tarda un minuto en ejecutarse, pero en realidad solo están en ejecución durante 30 segundos cada uno, mientras que el minuto restante representa el tiempo inactivo por lo que la utilización de la CPU es sólo del 50%. Sin embargo, si en el segundo cuando el proceso P1 está inactivo se ejecutase el proceso P2, el tiempo transcurrido para la ejecución de ambos procesos es de sólo un minuto y el tiempo de inactividad de la CPU es nulo por lo que la utilización de la CPU es del 100% incrementándose así la productividad.

Inicio Fin

Fin Inicio

Proceso P 2

Proceso P 1

Período de tiempo cuando el proceso esta activo

Período de tiempo cuando el proceso esta inactivo

En espera



2

Figura 4.2. Ejecución de procesos con multiprogramación

2. Planificación. 2.1. Colas de Planificación. Las posibilidades de que un proceso entre antes o después en ejecución dependerán directamente del estado en que se encuentre dicho proceso y de otras características que se verán más adelante. Mediante las colas de planificación conseguimos mantener una relación de los procesos que se encuentran en cada estado, es decir, las colas de planificación serán listas en cada una de las cuales se enumerarán los PID’s de los procesos que están en un determinado estado.

Figura 4.3. Representación de la planificación de procesos mediante un diagrama de colas

Cuando un programa entra en el sistema éste se coloca en la cola de trabajos donde están incluidos todos los programas que esperan una asignación de memoria del computador. Una vez listos para su ejecución y almacenados en la memoria principal éstos pasan a una lista denominada cola de procesos listos.

Inicio Fin

Fin Inicio

Proceso P 2

Proceso P 1

Período de tiempo cuando el proceso esta activo

Período de tiempo cuando el proceso esta inactivo

Cola de

procesos listos

CPU

Solicitud de E/S

Fin de la porción de tiempo

Se crea un hijo

En espera de una

interrupción

Ocurre una interrupción

Se ejecuta el hijo Termina el hijo

Cola de Termina el hijo



3

Si un proceso debe esperar a que ocurra un suceso determinado éste tendrá que esperar a que dicho evento ocurra puesto que hasta que no se origine no podrá volver a la actividad. La lista de procesos que esperan un dispositivo de E/S se denomina cola de dispositivos. 2.2. Planificación de Procesos. 2.2.1. Objetivos de un Buen Planificador. Cuando existen varios procesos listos para la ejecución, el sistema operativo debe decidir cuál de ellos se ejecuta primero. La parte del sistema operativo que se encarga de tomar esta decisión se llama planificador y el criterio que utiliza se llama algoritmo de planificación. A la hora de juzgar si un algoritmo de planificación es bueno, se pueden aplicar los siguientes criterios:

1. Equidad: Ha de asignarse el procesador a cada proceso con el mismo tiempo de utilización.

2. Eficiencia: El funcionamiento del procesador ha de aprovecharse al cien

por cien.

3. Tiempo de respuesta: El tiempo de respuesta debe minimizarse al máximo.

4. Tiempo de proceso o espera: El tiempo de espera de los usuarios ha de

minimizarse al máximo.

5. Productividad: Debe conseguirse maximizar el número de trabajos por unidad de tiempo.

Se puede observar que algunos de estos objetivos son contradictorios.

Por ejemplo, si se desea mantener equidad, los procesos cortos se ven penalizados puesto que posiblemente esperarán mucho más que los procesos largos. Además de este problema, cabe decir que el comportamiento de los procesos es único e impredecible (este es el caso de que un proceso puede bloquear el sistema ante la espera de la aparición de un evento). Estos son los problemas del planificador.

Para evitar ambos errores lo que se pretende es llegar a un compromiso entre todos los criterios de forma que se optimice el promedio. Además, existe un mecanismo de suspensión de ejecuciones de procesos que monopolizan el procesador. Este es conocido con el nombre de planificación expulsiva. Sin embargo, otro mecanismo es el de planificación no expulsiva, en la que el proceso, una vez que ha conseguido “adueñarse” de la CPU, es él mismo quien decide cuando dejarla.



4

2.2.2. Estructura de la Planificación. Las decisiones de la planificación se pueden efectuar en una de las cuatro circunstancias siguientes:

1. Cuando un proceso cambia de estado de ejecución a estado de espera. 2. Cuando un proceso cambia de estado de ejecución a estado de listo. 3. Cuando un proceso pasa de estado de espera a estado listo. 4. Cuando termina un proceso.

2.2.3. El Despachador. El despachador o dispacher (que debe ser lo más rápido posible) es el módulo que realmente entrega el control de la CPU al proceso seleccionado por el planificador (el planificador es el que decide). Esto implica:

• Cambiar a modo usuario. • Cambiar de contexto. • Saltar a la posición adecuada para reiniciar la ejecución.

2.3. Algoritmos de Planificación. 2.3.1. Criterios para Comparar Algoritmos de Planificación. Los distintos algoritmos de planificación pueden favorecer a un tipo determinado de procesos en lugar de a otro. Por lo tanto, para seleccionar el algoritmo adecuado para una situación determinada, se deben evaluar cada una de las propiedades de todos los algoritmos. Para poder comparar todos los algoritmos necesitaremos emplear los siguientes criterios:

• Utilización de la CPU: Queremos que la CPU se mantenga ocupada tanto como sea posible.

• Productividad: Será necesario que consigamos la situación óptima para

que nuestro sistema ejecute un número máximo de tareas por unidad de tiempo.

• Tiempo de retorno: Necesitaremos disminuir el tiempo que tarda en

ejecutarse un proceso, es decir, disminuir:

- Los tiempos de espera en memoria. - Los tiempos de espera en la cola de procesos listos.

- Los tiempos de ejecución en la CPU.

- El tiempo efectuando operaciones de E/S.



5

• Tiempo de espera: Este criterio le da importancia únicamente a la cantidad de tiempo que el proceso espera en cola de procesos listos, de modo que en vez de tener en cuenta el tiempo de retorno, se considera solamente el tiempo de espera para cada proceso.

• Tiempo de respuesta: En este caso, nos fijamos en el tiempo que

transcurre desde la presentación de una solicitud hasta que se produce la primera respuesta. Este criterio suele emplearse en sistemas interactivos.

2.3.2. Tipos de Algoritmos de Planificación. i) Servicio por orden de llegada (FCFS: “First Come, First Server”). En este algoritmo de planificación, la CPU se asigna a todos los procesos en el mismo orden en que la solicitan. Supongamos los siguientes tres procesos P1, P2 y P3.

PROCESO INSTANTE DE LLEGADA TIEMPO DE CPU P1 0 24 P2 0 3 P3 0 3

Se puede observar que pueden darse casos muy distintos. Caso 1: Orden de llegada P1, P2, P3 � En este caso, el tiempo de espera es (0+24+27)/3=17.

Figura 4.4. Representación del resultado de ejecutar los procesos P1, P2 y P3

Caso 2: Orden de llegada P2, P3, P1. � En este caso, el tiempo de espera es (0+3+6)/3=3.

Figura 4.5. Representación del resultado de ejecutar los procesos P2, P3 y P1

Se puede observar que el tiempo de espera es muy variable en función a la llegada de los procesos y de la duración de la ejecución. Se produce el efecto convoy, es decir, los trabajos largos retrasan a los cortos. Puesto que es un sistema sin expulsión, una ejecución larga puede provocar una espera larga a otros procesos.

P1

0 3 6 30

P3

P1 P2 P3

0 24 27 30

P2



6

ii) Prioridad al trabajo más breve (SJF: “Shortest Job First”). Este algoritmo da prioridad al proceso que va a necesitar menos tiempo para “ejecutarse entero” en la CPU. Este algoritmo funciona de la siguiente manera:

1. Se asocia a cada tarea un tiempo aproximado de ejecución. 2. La CPU es asignada al proceso con menos tiempo asociado.

3. No existe expulsión puesto que, una vez asignada la CPU, el

proceso o tarea conserva el control sobre la CPU hasta que termina.

La dificultad de este algoritmo es la estimación del tiempo que va a utilizar la CPU un determinado proceso. iii) Prioridad al que le resta menos tiempo (SRTF: “Shortest Remaining Time First”). En este algoritmo se da más prioridad al proceso que le resta menos tiempo de CPU para finalizar. En este caso, si llega un proceso a la cola de procesos preparados y solicita un tiempo de CPU inferior al tiempo que le falta al proceso en ejecución para abandonar la CPU, entonces el nuevo proceso se adueña de la CPU y el proceso que se estaba ejecutando pasa a la cola de procesos preparados. A pesar de las ventajas de este algoritmo, éste presenta dos serios inconvenientes:

• El intervalo de la CPU es difícil de predecir. • Posibilidad de inanición: los trabajos largos no se ejecutarán mientras

hayan trabajos cortos. iv) Planificación por prioridades. Estos algoritmos asocian a cada proceso un número entero llamado prioridad de modo que se asigna a la CPU el proceso con mayor prioridad (dependiendo del criterio tomado). Podemos encontrar diferentes tipos:

• Algoritmos con expulsión o sin expulsión. • Prioridades estáticas o dinámicas:

� Prioridades estáticas: En estos, la prioridad se asigna antes de la ejecución y no cambia. Esto provoca, generalmente, la aparición del problema de inanición puesto que procesos con baja prioridad no se ejecutarían nunca.



7

� Prioridades dinámicas: La prioridad cambia con el tiempo de modo que se soluciona el problema de inanición utilizando un esquema de prioridades dinámicas donde la prioridad aumenta con el tiempo de espera. Este mecanismo se conoce como actualización de prioridades.

v) Planificación por Turno Rotatorio. Este algoritmo, llamado también Round Robin, es de los más veteranos, sencillos y ampliamente utilizados. A cada proceso se le asigna un quantum (intervalo de tiempo), durante el cual el proceso puede ejecutarse. Si el proceso está todavía en ejecución cuando el quantum termina, se le expulsa del procesador, quedando libre para la ejecución de otros procesos. El único trabajo que debe realizar el planificador es el de mantener una lista de procesos ejecutables. Cuando a un proceso se le termina el quantum, éste pasa al final de la lista.

Figura 4.6. Lista de procesos ejecutables con el proceso B ejecutándose y lista de procesos ejecutables después de terminar el cuanto de B

Cabe decir que asignar un valor muy pequeño al quantum aumenta demasiado el número de cambios de contexto y disminuye la eficiencia del procesador. Por otro lado, darle al quantum un valor demasiado grande aumenta los tiempos de respuesta a peticiones cortas pudiendo llegar a degenerar en un algoritmo FCFS.

Veamos el siguiente ejemplo:

Procesos T. llegada Duración P1 0 16 P2 0 3 P3 0 11

CPU

CPU

C

F

A

H

D

B

F

A

H

D

C

B

P1

P1

P1

P1

P2

P3

P3

P3

0 4 7 11 15 19 23 26 30

Diagrama de Gantt

Quantum q = 4



8

Figura 4.7. Gráfica de Gantt y cronograma del resultado de ejecutar P1, P2 y P3 con RR

153

23157)(P espera de medio Tiempo

41


144


3

2

1

=++=

==

=+++=

Se puede observar que el tiempo medio de espera es (14+4+15)/3=11.

vi) Planificación con clases de prioridades. En este algoritmo, los procesos se pueden clasificar en varios grupos:

• Sistemas. • Interactivos.

En este caso la cola de procesos se divide en varias colas donde cada

una posee su propio algoritmo de planificación. Además, hay que decir que existe un algoritmo de planificación entre colas que las relaciona.

Veamos el siguiente ejemplo:

Figura 4.8. Ejemplo de planificación con múltiples colas

FCFS (prioridad 10)

PRIO (prioridad 8)

RR (prioridad 6)

SJF (prioridad 4)

Procesos del sistema

Usuarios Privilegiados

Procesos Interactivos

Procesos por lotes

Cronograma de procesos

P1

P2

P2



9

Cada clase tiene su propia prioridad y, además, su propio algoritmo de planificación. Aparte, es necesario asignar una política de planificación entre colas.

Este mecanismo puede provocar la aparición de un serio problema puesto que si no dejan de llegar procesos a una cola de prioridad alta, los procesos que pertenezcan a otro grupo o clase con prioridad menor no se podrán ejecutar. Por lo tanto, para evitar esta merma se puede decidir asignar a cada cola un intervalo de tiempo de ejecución, y así permitir que se ejecuten todas a pesar de una sobrecarga en colas con altas prioridades.

vii) Planificación con múltiples colas realimentadas. En este caso, un proceso puede cambiar de cola de acuerdo a:

- Los procesos con un tiempo de espera acumulado elevado son promocionados a una cola con prioridad superior (veteranía).

- Los procesos con un tiempo de utilización de CPU elevado son

degradados a una cola con prioridad inferior.

?1


1

Planificación Conceptos de Planificación

? El objetivo de la multiprogramación es que en todo momento haya un proceso en ejecución (maximiza la utilización)

? Planificación: forma o criterio que se sigue a la hora de decidir que proceso debe entrar en ejecución.

? La tarea de planificación es la más crítica de un SOTR.

? Ventajas de la multiprogramación:

? Aumento de utilización de CPU (% de actividad de la CPU)

? Mayor productividad (cantidad de trabajo por u.t.)


2

Planificación Multiprogramación: Ejemplo

? Un sistema con dos procesos P1 y P2. Cada proceso se ejecuta durante 1 seg. y espera otro seg. Este esquema se repite 60 veces.

Ejecución de procesos sin multiprogramación

Fin

Proceso P1

Inicio Inactivo;Espera

Inactivo;Espera

Fin

Proceso P2

InicioEn espera

Inactivo;Espera

Inactivo;Espera

Inactivo;Espera

Inactivo;Espera

Ejecución de procesos con multiprogramación

Proceso P1

Inicio

Inactivo;Espera

Inactivo;Espera Fin

Proceso P2

Inicio Inactivo;Espera

Inactivo;Espera

Fin

Inactivo;Espera

Inactivo;Espera

Utilización: 50%

Utilización: 100%

?2


3

Planificación Colas de Planificación (I)

? Un proceso tendrá más o menos posibilidad de entrar en ejecucióndependiendo del estado en que se encuentre.

? Es necesario mantener una relación de los procesos que se encuentran en cada estado ? Colas de planificación

? Cuando un programa desea entrar en el sistema se coloca en una cola de trabajos a esperar que se le asigne memoria.

? Cuando a un trabajo se le asigna memoria entra en la cola de procesos listos

? Cuando un proceso realiza una operación de E/S pasa a una cola de dispositivo asociada al dispositivo en el que realiza la operación de E/S


4

Planificación Colas de Planificación (II)

? Una representación común para analizar la planificación de procesos en el diagrama de colas

En espera de una interrupción

Fin de la porción de tiempo (quantum)

Se crea un hijo

Solicitud de E/SCola de E/S

Cola de procesos listos

CPU

E/S

Termina el hijo

Se ejecuta el hijo

Ocurre una interrupción

?3


5

Planificación El planificador (I)

? Planificador: parte del SO que se encarga de tomar la decisión de qué proceso entra en ejecución

? Algoritmo de planificación: criterio que utiliza el planificador para designar el proceso que entra en ejecución

? Objetivos de un buen planificador:

? Equidad

? Eficiencia (100% utilización)

? Minimizar el tiempo de espera

? Aumentar el rendimiento (máximo número de trabajos por u.t.)


6

Planificación El Planificador (II)

? Problemas de un planificador:

? Alcanzar todos los objetivos provoca contradicciones? El comportamiento de los procesos es único e impredecible

? El SO debe evitar que un proceso “monopolice” el uso del procesador

? El SO debe ejecutar cada cierto tiempo el planificador. Si el planificador es capaz de quitar a un proceso el procesador, la planificación denomina expulsiva (preemptive)

? Si cuando un proceso consigue el procesador ya no lo cede hasta que termina, se dice que la planificación es no expulsiva

?4


7

Planificación Estructura de la Planficación

? Las decisiones de la planificación se pueden efectuar en una de las cuatro circunstancias siguientes:

? Un proceso pasa de estado de ejecución a estado de espera? Un proceso pasa de estado de ejecución a estado listo? Un proceso pasa de estado de espera a estado listo? Cuando termina un proceso

? En el primer y último caso no hay opción en términos de planificación

? En el resto de casos es el planificador quien retira el procesador al proceso mediante una política expulsiva


8

Planificación El despachador (Dispatcher)

? El planificador simplemente DECIDE que proceso sale o entra al procesador

? El despachador se encarga de entregar o quitar el control de la CPU a un determinado proceso

? Tareas del despachador

? Cambiar de contexto? Cambiar a modo usuario? Saltar a la posición adecuada del programa de usuario para reiniciar la

ejecución.

? Características del despachador: ser lo más rápido posible

?5


9

Planificación Algoritmos de Planificación (I)

? Los distintos algoritmos de planificación tienen propiedades diferentes y pueden favorecer o perjudicar a un tipo u otro de procesos.

? Normalmente se elegirá un algoritmo u otro en función del propósito del sistema

? Para comparar los algoritmos de planificación se han propuesto varios criterios:

? Utilización de CPU? Productividad? Tiempo de retorno? Tiempo de espera? Tiempo de respuesta


10

Planificación Algoritmos de Planificación (II)

? Es deseable maximizar la utilización de CPU y la productividad, y minimizar los tiempos de retorno, de espera y de respuesta

? Puesto que conseguir todo lo anterior es imposible (contradictorio) lo que se desea es llegar a un compromiso entre todos los criterios de forma que se optimice el promedio.

? Algoritmos:

? Por orden de llegada (FCFS)? Prioridad al trabajo más breve (SJF)? Prioridad al que resta menos tiempo (STRF)? Planificación por prioridades (estáticas o dinámicas)? Planificación circular o “Round Robin” (RR)? Planificación con clases de prioridades? Planificación con múltiples colas realimentadas

?6


11

Planificación Algoritmo FCFS

? La CPU se asigna a todos los procesos en el mismo orden en que lo solicitan

? Propiedades

? No optimiza el tiempo de espera: muy variable en función del orden de llegada y de la duración de intervalos de CPU

? Efecto convoy: los trabajos largos retrasan a los cortos

? No adecuado para sistemas interactivos

? Muy fácil de implementar (cola FIFO)


12

Planificación Algoritmo FCFS: Ejemplo

Proceso Instante de llegada Tiempo de CPU

P1 0 24

P2 0 3

P3 0 3

Caso 1: Orden de llegada P1, P2, P3

Caso 2: Orden de llegada P2, P3, P1

P1

P1

P2

P2 P3

P3

0 3 6 30

300 2724

Consideremos los procesos P1, P2 y P3 cuyo comportamiento se muestra en la tabla adjunta

?Caso 1: orden de llegada P1, P2, P3. Tiempo medio de espera (0 + 24 + 27)/3 = 17

?Caso 2: orden de llegada P2, P3, P1. Tiempo medio de espera (6 + 0 + 3)/3 = 3

?7


13

Planificación Algoritmo SJF

? Este algoritmo da prioridad al proceso que va a necesitar menos tiempo de CPU (mejora el tiempo medio de espera)

? Funcionamiento:

? Asocia a cada proceso un tiempo aproximado de utilización de CPU? Asigna la CPU al proceso con menor tiempo asociado? Cuando un proceso consigue la CPU la conserva hasta que decide liberarla

(no existe expulsión)

? Inconvenientes

? Estimación del tiempo de utilización de CPU por parte de un proceso (a veces se modela con técnicas estadísticas)


14

Planificación Algoritmo SRTF

? Da prioridad al proceso que le resta menos tiempo de CPU para terminar (variante del SJF con expulsión)

? Optimiza la media del tiempo de espera

? Funcionamiento:

? Los procesos llegan a la cola y solicitan un intervalo de CPU? Si dicho intervalo es inferior al que le falta al proceso en ejecución para

abandonar la CPU, el nuevo proceso pasa a la CPU y el que se ejecutaba a la cola de preparados.

? Inconvenientes:

? El intervalo de CPU es difícil de predecir? Posibilidad de inanición: los trabajos largos no se ejecutarán mientras

hayan trabajos cortos

?8


15

Planificación Planificación por prioridades

? Se asocia a cada proceso un número entero llamado prioridad de acuerdo con algún criterio.

? Se asigna la CPU al proceso con mayor prioridad? Variantes:

? Algoritmos con expulsión o sin expulsión? Prioridades estáticas o dinámicas

• P. estáticas: se asigna antes de la ejecución y no cambia• P. dinámicas: cambia con el tiempo

? Propiedades:? Con p. estáticas aparece el problema de inanición: los procesos con baja

prioridad no se ejecutan nunca (poco equitativo)? El problema anterior se soluciona con la actualización de prioridades (p.

dinámicas): la prioridad de un proceso aumenta con el tiempo de espera


16

Planificación Turno Rotatorio o Round Robin (I)

? Es de los más utilizados, sencillos y equitativos.? A cada proceso se le asigna un intervalo de tiempo llamado cuanto o

quantum.? Un proceso se ejecuta durante ese cuanto de tiempo. Si cuando acaba el

cuanto no ha terminado su ejecución, se le expulsa de la CPU dando paso a otro proceso.

? Si un proceso termina antes del cuanto, se planifica un nuevo procesoCPU

B C F A H D

a)CPU

C F A H D B

b)

?9


17

Planificación Turno Rotatorio o Round Robin (II)

0 15 19

P1 P2

304 7 11

Diagrama de Gantt

P3 P1 P3 P1 P3 P1

23 26

Cronograma por procesos

P1P2P3

Procesos T. Llegada DuraciónP1 0 16P2 0 3P3 0 11

Quantum q=4


18

Planificación Turno Rotatorio o Round Robin (III)

? Valor del “quantum” de tiempo

? Para q grandes: el algoritmo degenera en un algoritmo FCFS.? Para q pequeños: q ha de ser grande respecto al tiempo necesario para el

cambio de contexto, sino la sobrecarga introducida es muy alta. ? Regla práctica: El 80% de los intervalos de CPU han de ser inferiores al

“quantum” de tiempo.

? Propiedades

? Equitativo? Fácil de implementar

?10


19

Planificación Planificación con clases de Prioridades

? Los procesos se clasifican en distintos grupos: sistema, interactivos, tiempo real,...

? La cola de procesos preparados consiste en varias colas donde cada cola tiene su propio algoritmo y además, existe un algoritmo entre colas (p.e. RR con q elevado)

ProcesosSistema

UsuariosPrivilegiados

ProcesosInteractivos

Procesospor lotes

FCFS (prio 10)

PRIO (prio 8)

RR (prio 6)

SJF (prio 4)

Cola de procesos preparados


20

Planificación Múltiples colas relimentadas

? Existen diferentes colas de procesos preparados.

? Cada cola posee una política de planificación y una prioridad asignada

? Un proceso puede cambiar de cola de acuerdo a un esquema de actualización de prioridades

? Los procesos con tiempo de espera acumulado elevado pasan a una cola de nivel superior

? Los procesos con tiempo de utilización de CPU elevados son degradados a una cola inferior

?11


21

Planificación Evaluación de Algoritmos

? Para seleccionar un algoritmo ? Seleccionar un criterio (utilización, t. de respuesta, t. espera, ...)? Estudiar la adaptación del algoritmo a esos criterios.

? Métodos de evaluación de algoritmos? Evaluación analítica

• Mediante modelo determinista• Mediante modelos de colas

? Simulación

?1


1

FuncionesPOSIX (III)

Semáforos POSIX (I)

? Pertenecen al estándar POSIX.1b y son relativamente recientes (1993)

? Variable de tipo sem_t sobre la cual se pueden realizar las funciones clásicas de los semáforos

? POSIX define dos tipos

? Semáforos no nombrados: se puede utilizar por el proceso que lo crea y por su descendencia

? Semáforos nombrados: se puede utilizar por el proceso que lo crea y por cualquier otro aunque no tenga relación con el creador

? En ambos tipos la declaración es igual

#include <semaphore.h>set_t semaforo;


2


Semáforos POSIX (II)

? POSIX no especifica la naturaleza del tipo sem_t, basta con saber que almacena toda la información referente al semáforo

? Todas las llamadas de creación y manejo de semáforos devuelven -1 en caso de error y 0 (normalmente) en otro caso

? La mayor diferencia entre semáforos nombrados y no nombrado es la forma de crear e inicializar el semáforo.

? Los semáforos POSIX son semáforos contadores que tienen valores no negativos y deben ser inicializados antes de se usados

?2


3


Semáforos no nombrados (I)

? Inicialización: la inicialización de un semáforo no nombrado en POSIX se realiza con la función sem_init

? Inicializa sem para que contenga el valor value (>0)? value indica el número de procesos que puede acceder al recurso que

asociado al semáforo? pshared a 0 indica que el semáforo sólo se puede utilizar por el proceso que

lo crea; si es distinto de cero, el semáforo puede ser utilizado por cualquier proceso (pariente del creador)

#include <semaphore.h>int sem_init (sem_t *sem, int pshared, unsigned int value);


4


Semáforos no nombrados (II)

? sem_destroy : destruye un semáforo

? Si un proceso intenta destruir un semáforo que tiene a otro proceso en espera, sem_destroy devuelve un mensaje de error

? sem_wait: operación P sobre un semáforo

? Decrementa el contador del semáforo? Si el valor del semáforo es 0, sem_wait efectúa un bloqueo del proceso

llamante hasta que el semáforo sea incrementado

#include<semaphore.h>int sem_destroy(sem_t *sem)

#include<semaphore.h>int sem_wait(sem_t *sem)

?3


5


Semáforos no nombrados (III)

? sem_trywait: como sem_wait pero en lugar de bloquear al proceso, no hace nada y devuelve -1

? sem_post: incrementa el valor del contador del semáforo (operación V)

? sem_getvalue:obtiene en sval el valor del contador del semáforo

#include<semaphore.h>int sem_wait(sem_t *sem)

#include<semaphore.h>int sem_post(sem_t *sem)

#include<semaphore.h>int sem_getvalue(sem_t *sem, int *sval);


6


Semáforos nombrados (I)

? Sincronizan procesos que no tienen ninguna relación entre sí.

? Los semáforos nombrados poseen:? Nombre? Identificador de usuario? Identificador de grupo? Permisos de acceso

? El nombre de un semáforo es una cadena de caracteres (con las mismas restricciones de un nombre de fichero). Además? Si el nombre (ruta) es relativa, sólo puede acceder al semáforo el proceso

que lo crea? Si la nombre comienza por “/”, el semáforo puede ser compartido por

cualquier proceso

?4


7


Semáforos nombrados (II)

? sem_open: devuelve un identificador que es utilizado por sem_wait, sem_trywait, sem_post, sem_destroy y sem_getvalue para referirse a dicho semáforo

? oflag determina si se accede a un semáforo ya creado o se debe crear uno nuevo? Si oflag es 0 se indica que se quiere acceder a un semáforo creado (si no

existe, sem_open devuelve -1)? Si oflag tiene el valor de O_CREAT, o O_CREAT | O_EXECL se utiliza la

segunda sintaxis presentada arriba

#include <semaphore.h>sem_t *sem_open (const char *name, int oflag);sem_t *sem_open (const char *name, int oflag, mode_t mode, unsigned int value);


8


Semáforos nombrados (II)

? Según oflag• O_CREAT: sem_open crea un semáforo si no existe. Si existe, accede al semáforo e

ignora los parámetros restantes• O_CREAT | O_EXECL: sem_open crea un semáforo si no existe. Si existe se

devuelve -1

? En los casos necesarios, mode especifica los permisos con los que se crea el semáforo (iguales que en open) y value especifica el valor inicial del semáforo creado

? sem_close: libera los recursos que el sistema asigna a un proceso cuando trabaja con un determinado semáforo

? No necesariamente elimina el semáforo, sólo lo hace inaccesible al proceso

#include <semaphore.h>int sem_close (sem_t *sem);

?5


9


Semáforos nombrados (III)

? sem_unlink: elimina un semáforo nombrado

? Si otros procesos hacen referencia al semáforo, sem_unlink pospone la destrucción.

? Las llamadas sem_open con el mismo nombre de semáforo después de hacer sem_unlink se refieren a otro semáforo (aun cuando aun haya procesos utilizando el semáforo)

#include <semaphore.h>int sem_unlink (sem_t *sem);

1. Threads POSIX 1

2. Gestión Básica de Threads 1

3. Atributos de los Threads 6

4. Planificación de Procesos 8

4.1. Planificación de Procesos en UNIX 8

4.1. Planificación de Threads 8

Resumen del tema V – Funciones POSIX 2

Resumen del tema V – Funciones POSIX 2

1. Threads POSIX.

La característica en común que tienen ambas bibliotecas es que las dos contemplan la creación y destrucción dinámica de threads.

Threads POSIX: Éstos se valen de objetos atributos para representar sus propiedades. Threads Solaris: En este caso, se establecen explícitamente las propiedades de los threads (provocando llamadas con largas listas de parámetros).

2. Gestión Básica de Threads.

#include <pthread.h>

int pthread_create (pthread_t *tid, const pthread_attr_t *attr, void* (*start_routine)(void), void *arg); #include <pthread.h>

pthread_t pthread_self (void *value_ptr); #include <pthread.h>

int pthread_exit (void *value_ptr); #include <pthread.h>

int pthread_join (pthread_t pthread, void **value_ptr);

3. Atributos de los Threads.

PROPIEDAD FUNCIÓN Observaciones Inicialización

pthread_attr_init pthread_attr_destroy

Inicializa un objeto atributo Hace que el valor del objeto atributo no sea válido

Tamaño de la pila pthread_attr_setstacksize pthread_attr_getstacksize

obtener dirección establecer dirección

Dirección de la pila pthread_attr_setstackaddr pthread_attr_getstackaddr

obtener tamaño establecer tamaño

Estado de desconexión

pthread_attr_setdetachstate pthread_attr_getdetachstate

Se desconecta al thread en cuestión PTHREAD_CREATE_JOINABLE � no desconectado PTHREAD_CREATE_DETACHED � desconectado

Alcance

pthread_attr_setscope pthread_attr_getscope

Consulta el alcance Establece el alcance PTHREAD_SCOPE_PROCESS � A nivel de usuario PTHREAD_SCOPE_SYSTEM � A nivel de núcleo

Herencia pthread_attr_setinheritsched pthread_attr_getinheritsched

Politica de planificación pthread_attr_setschedpolicy pthread_attr_getschedpolicy

Parámetros de planificación pthread_attr_setschedparam pthread_attr_getschedparam

#include <sched.h>

sched_param scheduling_parametrers; int I;

scheduling_parameters.sched_priority = 17; I = sched_setscheduler (getpid (), SCHED_FIFO, &scheduling_parameters);

Sistemas Informáticos en Tiempo Real Tema V

Tema V Funciones POSIX 2

1

1. Threads POSIX.

Un sistema operativo que permita ejecutar threads, debe contener una librería que proporcione un sistema para gestionar las threads sin que el usuario perciba la complejidad de su manejo. Las bibliotecas de threads tanto Sun Solaris como POSIX cuentan con llamadas al sistema para el manejo y gestión de los threads (crear y destruir, manipular propiedades, comunicación,...). La característica en común que tienen ambas bibliotecas es que las dos contemplan la creación y destrucción dinámica de threads. Sin embargo, sendas bibliotecas poseen características que las diferencian:

• Threads POSIX: Éstos se valen de objetos atributos para representar sus propiedades. Varios threads pueden estar asociados al mismo objeto atributo de forma que cuando uno de estos atributos cambia, se refleja en todos los threads asociados a dicho objeto.

• Threads Solaris: En este caso, se establecen explícitamente las

propiedades de los threads (provocando llamadas con largas listas de parámetros). Éstos ofrecen un mayor control entre threads y sobre los recursos de los procesadores.

2. Gestión Básica de Threads.

Las funciones POSIX de gestión básica de threads son:

Función Descripción pthread_create Crea un thread para la ejecución de una función determinada. pthread_exit Causa la terminación de un thread pthread_attr_init Inicializa los atributos a su valor por defecto pthread_join Hace que el thread que lo invoca espere a que termine un thread determinado pthread_self Devuelve la identidad del thread que lo ha invocado

Tabla 5.1. Algunas funciones básicas de gestión de threads Un thread tiene asociados, entre otros, los siguientes parámetros:

• Un identificador TID (Thread identificator). • Una pila. • Una prioridad de ejecución.

Un thread se representa mediante un identificador TID que se puede

obtener realizando la llamada pthread_self(). La estructura de un thread (pthread_t) es transparente al usuario y ésta puede contener información adicional de programación y uso.

En POSIX cuando se crea un thread (éste se crea de forma dinámica ya que se puede crear en cualquier instante de tiempo), éste pasa directamente a la cola de threads preparados antes de comenzar su ejecución.



2

Veamos ahora una descripción de cada una de las llamadas:

• pthread_create(): Parámetros:

� tid: Apunta al ID del thread que se crea. � attr: Atributos del thread creado. � start_routine: Nombre de la función que queremos que ejecute el

thread. Es necesario tener en cuenta que es un puntero a una “función puntero” que devuelve un dato cuyo tipo no estás especificado y que no tiene argumentos.

� arg: Puntero a los argumentos que se pasan a la función. • pthread_self():

De este modo, obtendremos el TID cuyo tipo es una estructura de datos no visible para el usuario.

• pthread_exit(): Normalmente pondremos como argumento NULL a no ser que deseemos especificar que ha habido un error de otra forma. De este modo, se eliminará el thread devolviendo un 0 o, en caso contrario, la aparición de un error durante la terminación provocará un valor de retorno no nulo, cuyo valor corresponderá al valor que hayamos asignado a value_ptr. Ejemplo 1.

Escribir un programa que lance dos threads que ejecuten dos funciones. Las funciones asociadas a los threads deben escribir en pantalla Soy el thread x y estoy ejecutando func x . La función 1, func1, escribirá el mensaje a los 2 segundos de lanzar su ejecución, y la función 2, func2, lo hará a los 5 segundos.


int pthread_create ( pthread_t *tid, const pthread_attr_t *attr, void * (*start_routine)( void ), void *arg);


pthread_t pthread_self ( void *value_ptr);


int pthread_exit ( void *value_ptr);



3

+ Explicaciones:

• Siempre que se trabaje con threads, el paso de parámetros se realiza por medio de punteros y nunca por valor. Esta es la razón por la que a las funciones que ejecutan los threads se les pasa como parámetro un puntero a un dato no especificado.

• La función que ha de ejecutar el thread se tiene que pasar como un puntero a dicha función.

• No era necesario asignar el TID a cada thread pues en este caso no se utilizan pero se quería dejar patente que la función main() es en sí un thread y que se puede obtener el TID de un proceso en cualquier instante.

// Programa que muestra cómo crear threads #include <stdio.h> #include <stdlib.h> #include <pthread.h> /* Propotipos de las funciones que ejecuten los thr eads */ void *func1 ( void *); void *func2 ( void *); /* Declaración de los threads */ pthread_t thread1, thread2, thmain; pthread_attr_t attr; /*atributos de los threads*/ /*Definición de las funciones func1 y func2 */ void *func1 ( void *arg) { pthread_t tid = pthread_self (); /*se asigna el TID*/ printf (“Soy el thread 1 y voy a ejecutar func1.\n ”); sleep (2); printf (“Soy el thread 1 y he terminado de ejecuta r func1.\n”); pthrad_exit (NULL); /*Provoca la terminación del thread*/ } void *func2 ( void *arg) { pthread_t tid = pthread_self (); /*se asigna el TID*/ printf(“Soy el thread 2 y voy a ejecutar func2.\n” ); sleep (5); printf(“Soy el thread 2 y he terminado de ejecutar func2.\n”); pthread_exit (NULL); /*Provoca la terminación del thread*/ } /*Función main*/ void main ( void ) { thmain = pthread_self(); /*La propia función main es un thread*/ pthread_attr_init (&attr); /*Inicializa los parámetros por defecto*/ printf(“Soy la función main y voy a lanzar los dos threads \n”); pthread_create (&thread1, &attr, func1, NULL); pthread_create (&thread2, &attr, func2, NULL); printf(“Soy main: he lanzado los dos threads y ter mino.\n”); pthread_exit (NULL); }



4

Ejemplo 2.

Realizar un programa que lance un thread que ejecute una función que multiplica dos números. Los dos números se deben pasar a la función como argumentos en la llamada de creación del thread. Utilizar una estructura para el paso de parámetros.

// Programa que muestra el paso de parámetros en th reads #include <stdio.h> #include <stdlib.h> #include <pthread.h> /*Prototipos de las funciones que ejecutan los thre ads*/ void *func1 ( void *); // Estructura que contiene los datos a pasar como p arámetros // Un único parámetro se puede pasar directamente c on el operador typedef struct { int dato1, dato2; }datos; /*Declaración de los threads*/ pthread_t thread1, thmain; pthread_attr_t attr; /*atributos de los threads*/ /*Definición de las función func1*/ void *func1 ( void *arg) { int a,b; datos *p = ( datos *) (arg); pthread_t tid = pthread_self (); /*se asigna un identificador

al thread*/ a=(p->dato1); b=(p->dato2); printf (“Soy el thread 1 y voy a ejecutar func1.\n ”); printf(“La multiplicación es %d\n”, a*b); printf(“Soy el thread 1 y he terminado de ejecutar func1.\n”); pthread_exit (NULL); /*Provoca la terminación del thread*/ } /*Función main*/ void main( void ) { datos param; param.dato1=6 param.dato2=6; thmain = pthread_self (); pthread_attr_init (&attr); printf(“Soy la función main y voy a lanzar el thre ad.\n”); pthread_create (&thread1, &attr, func1, &param); printf (“Soy main: he lanzado el threads y termino. \n”); pthread_exit (NULL); }



5

• pthread_join(): Al igual que en otras llamadas, si todo ha funcionado correctamente, se devuelve un 0 mientras que si se da el caso de la aparición de un error, el valor de retorno no es nulo. Con esta llamada conseguiremos que un thread invocador espere a otro determinado. Esto puede ser provechoso cuando existe la posibilidad de cooperación entre threads. Ejemplo 3.

Realizar un programa que cree dos threads th1 y th2, que ejecuten dos funciones f1 y f2. Ambas funciones simplemente imprimirán un mensaje diciendo de qué función se trata y posteriormente esperarán 4 segundos la primera y 2 segundos la segunda. Además, la segunda función sólo se debe ejecutar cuando haya terminado la primera.

#include <pthread.h> int pthread_join (pthread_t pthread, void **value_ptr) ;

//Ejemplo de utilización de pthread_join #include <stdio.h> #include <stdlib.h> #include <pthread.h> /*Prototipos de las funciones que ejecutan los thre ads*/ void *f1 ( void *); void *f2 ( void *); /*Declaración de los threads*/ pthread_t th1, th2, thmain; pthread_attr_t attr; /*atributos de los threads*/ /*Definición de las funciones f1 y f2*/ void *f1 ( void *arg) { printf(“Soy el th1 y estoy ejecutando f1.\n”); sleep (2); printf(“Soy el thread 1 y termino.\n”); pthread_exit(NULL); } // � Continua



6

3. Atributos de los Threads.

Cada thread tiene asociado un objeto atributo que representa sus propiedades. Cabe la posibilidad de que varios threads puedan estar asociados al mismo objeto atributo de modo que cuando se cambie una propiedad del objeto atributo, todas las entidades del grupo adquieren la nueva propiedad. Excepto las dos primeras llamadas de la tabla siguiente, todas las funciones para obtener o establecer atributos tienen dos parámetros:

PROPIEDAD FUNCIÓN

Inicialización pthread_attr_init pthread_attr_destroy

Tamaño de la pila pthread_attr_setstacksize pthread_attr_getstacksize

Dirección de la pila pthread_attr_setstackaddr pthread_attr_getstackaddr

Estado de desconexión pthread_attr_setdetachstate pthread_attr_getdetachstate

Alcance pthread_attr_setscope pthread_attr_getscope

Herencia pthread_attr_setinheritsched pthread_attr_getinheritsched

Politica de planificación pthread_attr_setschedpolicy pthread_attr_getschedpolicy

Parámetros de planificación pthread_attr_setschedparam pthread_attr_getschedparam

Tabla 5.2. Resumen de propiedades que se pueden establecer para atributos de threads

// � Continuación void *f2 ( void *arg) { int err; printf(“Soy el th2 y voy a esperar que th1 termine .\n”); if (err = pthread_join(th1, NULL)) printf (“Error al esperar a th1.\n”); else { printf(“Soy th2, th1 ha terminado y estoy ejecuta ndo f2.\n”); sleep (2);

} pthread_exit(NULL); } /*Función main*/ void main( void ) {

thmain = pthread_self(); pthread_attr_init (&attr); printf(“Soy la función main y voy a lanzar los dos threads \n”); pthread_create (&th1, &attr, f1, NULL); pthread_create (&th2, &attr, f2, NULL); printf(“Soy main: he lanzado los dos threads y term ino.\n’’); pthread_exit (NULL);

}



7

Veamos a continuación cada una de las funciones:

• Inicialización y destrucción:

pthread_attr_init() � Inicializa un objeto atributo a los valores por defecto. pthread_attr_destroy() � Hace que el valor del objeto atributo no sea válido (POSIX desconoce su comportamiento una vez destruido). Ambas solo tienen como argumento un puntero a un objeto de atributo de thread.

• Dirección y tamaño de la pila:

pthread_attr_getstackaddr(): obtener dirección. pthread_attr_setstackaddr(): establecer dirección. pthread_attr_getstacksize(): obtener tamaño. pthread_attr_setstacksize(): establecer tamaño.

• Estado de desconexión:

Un thread puede estar en dos posibles estados de cara a los demás:

- undetached: cuando se está en estado de conexión, cualquier otro thread puede esperar a que este termine para realizar una tarea.

- Detached: en este estado es imposible que otro thread pueda esperar a que finalice, puesto que los demás no tienen constancia de si ha terminado o no.

Las funciones son:

pthread_attr_getdetachstate(): Examina si está o no desconectado. Los posibles valores son:

PTHREAD_CREATE_JOINABLE � no desconectado. PTHREAD_CREATE_DETACHED � desconectado.

pthread_attr_setdetachstate(): Se desconecta al thread en cuestión. Establece el valor del detachstate a uno de los anteriores.

• Alcance: Éste permitirá elegir en que modo se crea un thread:

PTHREAD_SCOPE_PROCESS � A nivel de usuario. PTHREAD_SCOPE_SYSTEM � A nivel de núcleo.



8

En este caso las funciones son:

pthread_attr_getscope(): Consulta el alcance. pthread_attr_setscope(): Establece el alcance. 4. Planificación de Procesos. 4.1. Planificación de Procesos en UNIX.

Existen n colas donde cada cola tiene asignado un valor de prioridad de modo que cada cola se planifica de forma independiente. POSIX define tres políticas:

- SCHED_FIFO: los procesos se planifican siguiendo un esquema expulsivo basado en prioridades.

- SCHED_RR: política preemtiva con esquema Round Robin basado en

prioridades.

- SCHED_OHTER: este tipo puede ser definido por el programador.

Los parámetros de planificación dependen de la política que se emplee y están metidos en la siguiente estructura:

Utilizando una estructura esta es susceptible de ser ampliada añadiendo nuevos campos. La llamada que permite cambiar la prioridad y la política de planificación es: Por ejemplo, si se quisiera cambiar la política de planificación de un proceso en ejecución SCHED_FIFO con prioridad 17, se tiene

struct sched_param{ int sched_priority; }; typedef struct sched_param sched_param;

int sched_setscheduler ( pid_t pid, int policy, sched_param *param);

#include <sched.h>

sched_param scheduling_parametrers; int I;

scheduling_parameters.sched_priority = 17; I = sched_setscheduler (getpid (), SCHED_FIFO, &sch eduling_parameters);



9

4.2. Planificación de Threads. � La política y atributos de planificación de un thread se encapsulan en un objeto (estructura) de tipo struc sched_param que contiende

- sched_policy: SCHED_FIFO, SCHED_RR, SCHED_OTHER.

- sched_priority: número entero. � El comportamiento real de la política de planificación depende del alcance del thread y de otros factores.

?1


1

Funciones POSIX II

Threads POSIX

? Un SO que soporte threads debe contener un paquete que proporcione un sistema en tiempo real para manejo de threads

? Dos bibliotecas principales de gestión de threads: Sun Solaris 2 y threads POSIX (pthreads)

? Ambos contemplan la creación y destrucción dinámica de threads

? Sun Solaris 2? Establecen explícitamente las propiedades de los threads? Ofrecen mayor control entre threads y recursos de procesadores? Normalmente sólo funcionan en Sun

? Pthreads? Se valen de objetos atributo para representar propiedades de los threads? Varios threads pueden estar asociados a un mismo objeto? Ofrecen un método más robusto de cancelación y terminación


2

Funciones POSIX II

Gestión básica de threads

? Funciones POSIX de gestión básica de threads

? Un thread tiene asociados (entre otros) los siguientes parámetros? TID? Pila? Prioridad de ejecución? Dirección de inicio de la ejecución

Función Descripición

pthread_create Crea un thread para ejecutar una función determinada

pthread_exit Causa la terminación de un thread

pthread_attr_init Inicializa los atributos del thread a su valor por defecto

pthread_join Hace que el thread que la invoca espere a que termine unthread determinado

pthread_self devuelve la identidad del thread que lo invoca

?2


3

Funciones POSIX II

Gestión básica de Threads (II)

? Un thread se representa mediante su TID de tipo pthread_t.

? Pthread_t es una estructura transparente al usuario y que depende de la implementación (pueden contener información adicional)

? Un thread es dinámico si se puede crear en cualquier instante de tiempo

? En POSIX, cuando un thread se crea se coloca en una cola de threads preparados

? Normalmente las llamadas al sistema para gestión de threads devuelven 0 si se ha llevado a cabo con éxito y 1 en caso de error


4

Funciones POSIX II

Llamadas para gestión de Threads (I)

? Creación de threads: pthread_create

? Parámetros? tid: apunta al thread que se crea? attr: atributos del thread creado (tipo pthread_attr_t)? start_routine: puntero a la función que debe ejecutar el thread? arg: puntero a los argumentos que se pasan a al afunción

#include <pthread.h>int pthread_create (pthread_t *tid, const pthread_attr_t *attr,void *(*start_routine)(void), void *arg);

?3


5

Funciones POSIX II

Llamadas para gestión de Threads(II)

? Obtener identificador de un thread (TID): pthread_self

? Terminar un thread: pthread_exit

? Inicializar un objeto atributo por defecto: pthread_attr_init

#include <pthread.h>pthread_t pthread_self (void *value_ptr);

#include <pthread.h>int pthread_exit (void *value_ptr);

#include <pthread.h>int pthread_attr_init (pthread_attr_t *attr);


6

Funciones POSIX II

Gestión básica de Threads: Ejemplo (I)

? La función que ejecuta el thread se pasa como un puntero a dichafunción

? Los parámetros de la función se pasan como un parámetro a void

? Se declara un thread para la función main (main es implícitamente un thread cuando se trabaja con threads)

? Es necesario inicializar los atributos de los threads (aunque sea por defecto)

?4


7

Funciones POSIX II

Llamadas para gestión de Threads(III)

? Dependencias entre threads: pthread_join, hace que el thread que la invoca espere a que termine un determinado thread

? Permite que varios threads cooperen en una tarea? thread es el nombre del thread que esperamos que termine? En value_ptr se almacena el código de salida del thread que termina (si es

NULL no guarda nada)

#include <pthread.h>int pthread_join (pthread_t thread, void **value_ptr);


8

Funciones POSIX II

Atributos de los Pthreads (I)

? Los atributos de los threads en POSIX se encapsulan en un objeto tipo atributo (pthread_attr_t)

? Este mecanismo permite asociar a un grupo de threads los mismos atributos

? Cuando cambia una propiedad del objeto atributo, cambia para todos los threads asociados a él

? POSIX proporciona llamadas para crear, inicializar, configurar y destruir elementos de un objeto atributo

?5


9

Funciones POSIX II

Atributos de los Pthreads (II)

? Algunas de las propiedades asociadas a los threads se muestran en la tabla siguiente

Propiedad Función

Inicialización pthread_attr_initpthread_attr_destroy

Tamaño de la pila pthread_attr_setstacksizepthread_attr_getstacksize

Dirección de la pila pthread_attr_setstackaddrpthread_attr_getstackaddr

Estado de desconexión pthread_attr_setdetachstatepthread_attr_getdetachstate

Alcance pthread_attr_setscopepthread_attr_getscope

Herencia pthread_attr_setinheritschedpthread_attr_getinheritsched

Política de planificación pthread_attr_setschedpolicypthread_attr_getschedpolicy

Parámetros de planificación pthread_attr_setschedparampthread_attr_getschedparam


10

Funciones POSIX II

Atributos de los Pthreads (III)

? Excepto pthread_attr_init y pthread_attr_destroy todas las funciones para obtener o establecer atributos tienen dos parámetros

? El primer parámetro es un puntero a un objeto pthread_attr_t y el segundo el valor del atributo que se desea cambiar

#include <pthread.h>#include <sched.h>int pthread_attr_setschedparam (pthread_attr_t *attr,

const struct sched_param *param);

?6


11

Funciones POSIX II

Algunos atributos de los pthreads(I)

? Inicialización y destrucción? pthread_attr_init: inicializa un objeto atributo a los valores por defecto

? pthread_attr_destroy: hace que el valor del objeto sea no válido (POSIX no especifica el comportamiento del objeto una vez destruido)

? Dirección y tamaño de pila? pthread_attr_getstackaddr: obtiene dirección

? pthread_attr_setstackaddr: establece dirección

? pthread_attr_getstacksize: obtiene tamaño

? pthread_attr_setstacksize: establece tamaño


12

Funciones POSIX II

Algunos atributos de los pthreads(II)

? Estado de desconexión: un thread puede estar en dos estados

? estado de conexión (undetached): los demás threads son conscientes de su existencia y pueden esperarlo (join)

? estado de desconexión (detached): los demás threads no tienen consciencia de su existencia (no se puede esperar)

? pthread_attr_getdetachstate: examina el detachstate de un objeto atributo.Este puede ser

• PTHREAD_CREATE_JOINABLE (no desconectado)• PTHREAD_CREATE_DETACHED (desconectado)

? pthread_attr_setdetachstate: establece el detachstate a uno de los valores anteriores

? Los threads desconectados invocan la llamada pthread_detach cuando terminan para liberar los recursos

?7


13

Funciones POSIX II

Algunos atributos de los pthreads(III)

? Alcance: permite trabajar con distintos modelos de threads (si el sistema lo permite)? El atributo contentionscope puede ser

• PTHREAD_SCOPE_PROCESS: thread a nivel de usuario• PTHREAD_SCOPE_SISTEM: thread a nivel de núcleo

? pthread_attr_getscope: consulta el alcance de contención? pthread_attr_setscope: establece el alcance de contención


14

Funciones POSIX II

Conceptos de planificación en Unix (I)

? Unix utiliza un esquema de planificación por clases de prioridades (n colas con prioridad asociada donde cada cola se planifica de forma independiente)

? Cada proceso tiene una política y unos atributos de planificación asociados los cuales se pueden modificar de forma independiente

? POSIX define tres politicas

? SCHED_FIFO: FIFO expulsivo con prioridades? SCHED_RR: Round Robin (no se permite cambiar el quantum)? SCHED_OTHER: definida por el programador

?8


15

Funciones POSIX II

Conceptos de planificación en Unix (II)

? Los parámetros de planificación están encapsulados en una estructura

? La llamada que permite cambiar la prioridad y la política de planificación es sched_setscheduler

? Devuelve 0 si el cambio ha tenido éxito, 1 en caso de error

struct sched_param {int sched_priority;

}

int sched_setscheduler (pid_t pid, int policy, sched_param *param);


16

Funciones POSIX II

Conceptos de planificación en Unix (III)

? Ejemplo: Planificar un proceso con política SCHED_FIFO y prioridad 17

#include <sched.h>struct sched_param scheduling_parameters;int i;

sheduling_parameters.sched_priority = 17;i = sched_setscheduler(getpid(), SCHED_FIFO,

&scheduling_parameters);

?9


17

Funciones POSIX II

Planificación de threads (I)

? La política y atributos de planificación de un thread se encapsulan en un objeto (estructura) de tipo struc sched_param que contiene? sched_policy: SCHED_FIFO, SCHED_RR, SCHED_OTHER? sched_priority: número entero

? El comportamiento real de la política de planificación depende del alcance del thread y de otros factores

1. Introducción 1

2. Medida del Paso del Tiempo con Relojes 1

2.1. Reloj Calendario en POSIX 2

2.2. Reloj de Tiempo Real en POSIX 2

2.3. Medida de Tiempo del Sistema 5

3. Retardos 6

3.1. Retardos Relativos 6

3.2. Retardos Absolutos 7

4. Límites Temporales 8

5. Temporizadores 8

Resumen del tema VI – Relojes

Resumen del tema VI – Relojes

Sistemas Informáticos en Tiempo Real Tema VI

Tema VI Relojes POSIX

1

1. Introducción.

Durante este tema estudiaremos y analizaremos los mecanismos básicos, relacionados con el manejo del tiempo, para:

• Medir el paso del tiempo.

• Retrasar la ejecución de una tarea durante un tiempo.

• Establecer límites temporales.

• Establecer relojes temporizados. 2. Medida del Paso del Tiempo con Relojes.

Obviamente, el objetivo de todo reloj es establecer una representación del tiempo, es decir, representar una magnitud física fundamental conocida como tiempo (la unidad en el Sistema Internacional es el segundo). Las dos tareas necesarias en la medida del tiempo en una aplicación de tiempo real son:

• Medida de intervalos de tiempo: Distancia, en tiempo real, entre dos

valores de tiempo de reloj.

• Medida de tiempo absoluto: Distancia, en tiempo real, entre un valor de tiempo de reloj y una referencia externa considerada origen.

Para la medida de valores absolutos es preciso definir un sistema de

referencia que puede ser de un tipo como:

• Locales: El tiempo de arranque o creación del sistema.

• Astronómicos:

− Tiempo universal. − Tiempo oficial: Tiene en cuenta el huso horario y la corrección

estacional.

• Atómicos:

− Tiempo atómico internacional.

− Tiempo universal coordinado.

Generalmente un sistema de referencia se basa en una escala de tiempo cuyo origen se denomina “época”.



2

En POSIX, la representación del tiempo se realiza mediante un número entero de segundos (32 bits) y un número entero de nanosegundos (32 bits). Por tanto, se conoce que la resolución es de 1 ns. El sistema de referencia utilizado para las medidas absolutas es el tiempo universal 1/1/1970 a las 0 horas (de donde se descubre que el intervalo máximo de medida es de 232 segundos, es decir, más de 136 años). La granularidad depende de la implementación.

No existe en POSIX una definición de intervalos de tiempo. Los intervalos

de tiempo se miden por tanto por diferencia entre valores de reloj. Podemos decir que existen dos tipos de reloj en POSIX:

• Reloj CALENDARIO en POSIX.

• Reloj de TIEMPO REAL en POSIX.

• Reloj de TEIMPO REAL en SV.

2.1. Reloj CALENDARIO en POSIX.

Este reloj proporciones una medida de tiempo con una resolución de 1 segundo. La sintaxis es:

El tipo de valor de reloj es time_t (entero de 32 bits). La función devuelve el tiempo transcurrido en segundos desde las 0 h del 1 de enero de 1970. Si tloc no es NULL guarda también la hora en *tloc.

Para realizar una conversión a unidades corrientes, es decir, para

obtener una cadena de caracteres con el tiempo formateado, utilizaremos la siguiente función:

2.2. Reloj de TIEMPO REAL en POSIX.

Estos relojes a diferencia de los anteriores, ofrecen una resolución teórica de 1 ns pero normalmente es de 20 ms. El tiempo se representa mediante la estructura timespec definida en <time.h>. Viene definido como:

#include <time.h>

time_t time (time_t *tloc);

#include <time.h>

char * ctime ( const time_t *clock);

struct timespec{ time tv_sec; /*SEGUNDOS*/ long tv_nsec; /*NANOSEGUNDOS*/ };



3

También los sistemas UNIX emplean la siguiente estructura tival que viene definida en <sys/time.h>:

Las diferentes funciones (Tiempo Real) son: • gettimeofday():

Con esta función conseguiremos leer el tiempo actual para el reloj. Su

sintaxis es: Esta función, utilizada para obtener el tiempo de reloj, devuelve la hora

en la estructura *tp (segundos y microsegundos). Si la función tiene éxito devuelve un 0, pero sino devolverá un 1. El apuntador tzp debe ser NULL.

• settimeofday():

Con esta función conseguiremos poner en hora el reloj. Dicha función

tiene la siguiente sintaxis:

Esta función, utilizada para configurar el tiempo de reloj, pone en hora

en la estructura *tp (segundos y microsegundos). Si la función tiene éxito devuelve un 0, pero sino devolverá un 1. El apuntador tzp debe ser NULL.

Es conocido que el tipo de dato clock_id sirve para identificar los

diferentes relojes. Por lo menos debe estar definido un reloj que abarque a todo el sistema que se identifique como CLOCK_REALTIME. Las funciones relacionadas con este tipo de dato (Tiempo Real de SV) son:

• clock_gettime(): Con esta función conseguiremos leer el tiempo actual para el reloj

clockid. Su sintaxis es:

struct timeval{ time _ tv_sec; /*SEGUNDOS*/ long tv_usec; /*MICROSEGUNDOS*/ };

#include <sys/time.h>

int gettimeofday ( struct timeval *tp, void *tzp);


int settimeofday ( struct timeval *tp, void *tzp);


int clock_gettime ( clockid_t clockid, struct timespec *tp);



4

Donde clockid es el reloj que queremos analizar (leer el tiempo) y el puntero a estructura tp va a ser donde se almacenen los valores de lectura.

• Clock_settime():

Con esta función conseguiremos poner en hora el reloj clockid. Dicha

función tiene la siguiente sintaxis: Donde clockid es el reloj que pretendemos configurar y en el puntero a

estructura tp irán implementados los valores de puesta en hora. • Clock_getres(): Con esta llamada conseguiremos conocer cual es la resolución de un

determinado reloj. Esta función tiene la sintaxis siguiente: A continuación veremos una serie de ejemplos.

Ejemplo 1:Uso de la función gettimeofday() Reloj CALENDARIO.


int clock_settime ( clockid_t clockid, struct timespec *tp);


int gclock_getres ( clockid_t clockid, struct timespec *tp);

#include <stdio.h> #include <math.h> #include <time.h> #include <sys/time.h> #define FIJAR_TMP() gettimeofday(&temp_1, 0) #define FIN_TMP() gettimeofday(&temp_2, 0) struct timeval temp_1, temp_2; void VER_TMP(char *txt) {

if (txt!=NULL) fprintf(stderr, "\n %s\n", txt); fprintf(stderr, "Tiempo consumido real: %2.6f s\n", (temp_2.tv_sec-temp_1.tv_sec) + (float) (temp_2.tv_usec-temp_1.tv_usec)/1000000 );

} main() {

int i; float sen; FIJAR_TMP(); for (i=0; i<10000; i++) sen=sin((float)i); FIN_TMP(); VER_TMP(“Ciclo for”); exit(0)

}



5

Ejemplo 2: Utilización de las funciones de medida de tiempo de reloj de TIEMPO REAL. 2.3. Medida de Tiempo del Sistema.

En un sistema multiprogramado los procesos se van alternando en el uso de la CPU siendo por tanto diferente la medida de tiempo transcurrido del sistema y el tiempo transcurrido de cada proceso. La sintaxis de la función básica gerusage() es:

#include <stdio.h> #include <math.h> #include <time.h> #define FIJAR_TMP() clock_gettime(CLOCK_REALTIME, &temp_1) #define FIN_TMP() clock_gettime(CLOCK_REALTIME, &temp_2) struct timespec temp_1, temp_2; void VER_TMP(char *txt) {

if (txt!=NULL) fprintf(stderr, "\n %s\n", txt); fprintf(stderr, "Tiempo consumido real: %2.9f s\n", (temp_2.tv_sec-temp_1.tv_sec)+ (float)(temp_2.tv_nsec-temp_1.tv_nsec)/1000000000 ) ;

} main() {


}

#include <sys/resource.h> int getrusage( int who, struct rusage * r_usage); struct rusage { struct timeval ru_utime; /* user time used */ struct timeval ru_stime; /* system time used */ /* .................. */ };



6

Ejemplo 3: Uso e la función gerusage() para medidas de tiempo del sistema. 3. Retardos.

Un retardo supone la suspensión de la ejecución de un proceso durante un cierto tiempo. Existen dos tipos de retardos:

• Retardo relativo: La ejecución se suspende durante un intervalo de

tiempo relativo al instante actual. • Retardo absoluto: La ejecución se suspende hasta que se llegue a un

instante determinado de tiempo absoluto. 3.1. Retardos Relativos.

Las funciones para el manejo de retardos relativos en POSIX son dos:

#include <stdio.h> #include <math.h> #include <resource.h> #define FIJAR_RES() getrusage(RUSAGE_SELF, &utiliz_1) #define FIN_RES() getrusage(RUSAGE_SELF, &utiliz_2); struct rusage utiliz_1, utiliz_2; /************************************************** ************* * Realiza una medida del tiempo consumido entre dos llamadas * Permite presentar también información de todos lo s recursos * consumidos. *************************************************** **************/ void VER_RES(char *txt) {

if (txt!=NULL) fprintf(stderr, "\n %s\n", txt); fprintf(stderr, "Tiempo consumido user: %2.6f s.\n" , (utiliz_2.ru_utime.tv_sec-utiliz_1.ru_utime.tv_sec) + (float) (utiliz_2.ru_utime.tv_usec- utiliz_1.ru_utime.tv_usec)/1000000 ); fprintf(stderr, "Tiempo consumido sys : %2.6f s.\n\ n", (utiliz_2.ru_stime.tv_sec-utiliz_1.ru_stime.tv_sec) + (float) (utiliz_2.ru_stime.tv_usec- utiliz_1.ru_stime.tv_usec)/1000000 );

} main() {


}



7

La función sleep() suspende el proceso durante los segundos indicados

de forma que el proceso es expulsado del uso de la CPU liberándola para otros procesos.

La función nanosleep() permite especificar retardos con una resolución de nanosegundos. La duración del retardo es *rqtp mientras que si rmtp es distinto de NULL se almacena en él la diferencia entre el tiempo especificado y el tiempo que el proceso ha estado dormido.

3.2. Retardos Absolutos.

No existe en POSIX un soporte directo para el manejo de retardos absolutos pero pueden aproximarse de la siguiente forma:

En el código anterior se plantean problemas ya que desde la lectura del

tiempo actual hasta que se llama a la función sleep() el proceso puede haber sido expulsado de la CPU. Para que fuera correcto, la lectura de tiempo y el cálculo de ret_absoluto – tiempo_actual debería ser atómica.

Tal y como se observa en el siguiente dibujo, se sabe que el valor

especificado en un retardo no es exactamente el tiempo realmente esperado puesto que al retardo especificado se le debe sumar la granularidad y el tiempo de respuesta de interrupción.

Retardo especificado

Instrucción de retardo

Error de granularidad

Interrupción inhibida

El retardo termina aquí

Preparado Ejecución

#include <unistd.h> #include <time.h>

unsigned int sleep ( unsigned int seconds); int nanosleep ( const struct timespec *rqtp, struct

timespec *rtmp);

tiempo_actual = time (); sleep (ret_absoluto – tiempo_actual);



8

4. Límites Temporales.

A menudo conviene limitar el tiempo durante el cual se espera que ocurra un suceso. Por ejemplo, cuando se accede a una sección crítica o se espera por un semáforo. Así mismo, cuando se está esperando una lecura desde un dispositivo físico, pueden producirse también situaciones de bloqueo.

POSIX incluye funciones para el manejo de temporizaciones asociadas a

diferenctes tipos de recursos. Por ejemplo, para el manejo de variables condicionals se puede limitar el tiempo durante el cual se espera una condición, mediante la siguiente función:

Para limitar el tiempo de espera de una señal se dispone de la siguiente

función (timeout es un intervalo relativo):

5. Temporizadores.

Adicionalmente a las esperas temporizadas se pueden crear temporizadores asociados a relojes. Éstos están asociados al manejo de señales de modo que cada temporizador se identifica mediante un valor de tipo timer_t, (entero) definido en la cabecera <time.h>. El valor de espera se especifica mediante un valor de tipo itimerspec,

Antes de usar un temporizador este debe ser creado mediante la siguiente función:


int pthread_cond_timedwait( pthread_cond_t *cpnd, pthread_mutex_t *mutex, const struct timespec *abstime);

#include <signal.h> int sigtimedwait( const sigset_t *set, siginfo *info,

const struct timespec *timeout);

cabecera <sys/time.h>: struct itimerspec {

struct timespec it_interval; /* periodo */ struct timespec it_value; /* expiración */

};



9

Esta función crea un temporizador asociado al reloj clock_id

(CLOCK_REALTIME). *evp indica el tipo de notificación que se produce al expirar el temporizador (se trata de un manejador de señal). El identificador del temporizador se devuelve en *timer_id.

Una vez creado el temporizador debe ser activado especificando si debe ser absoluto o relativo y el valor inicial. Para ello se dispone de la función:

El tipo de temporización se selecciona con el parámetro flan mientras

que el funcionamiento se repite periódicamente si value.it_interval >0. En *ovalue se devuelve el valor que quedaba de la temporización anterior. Finalmente, el temporizador se destruye una vez que no sea necesario mediante la función:

Ejemplo 4: Ejecución de tareas periódicas mediante temporizadores.

#include <signal.h> #include <time.h> int timer_create ( clockid_t clock_id, struct sigevent *evp,

timer_t *timerid);

int timer_settime ( timer_t timerid, int flag, const struct itimerspec *value, struct itimerspec *ovalue);

int timer_delete ( timer_t timerid);



10

/* *************************************************** ****************** Manejo de temporizadores con Threads Ejecución de tareas periódicas Autor: Luis M. Jiménez Fecha: 12-1-00 *************************************************** ****************** */ #define _REENTRANT #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <unistd.h> #include <pthread.h> #include <signal.h> #include "tiempo.h" #define SIGNUM SIGRTMAX #define PER_DEF 1000L // 1s por defecto #define NUM_PERIODOS 10 typedef struct {

int sig; long periodo;

} DatosTemp; void TestArg( int argc, char *argv[], long *per); void * ThreadPeriodico( void *arg); int InicializarSignal( int signum); int InicializarTemporizador( long msec, int signum, timer_t *ptemp); void ManejadorSig( int signo, siginfo_t *info, void *context); // � Continua



11

// � Continuación /* ****************************** función main ****************************** */ int main( int argc, char *argv[]) {

pthread_t th_id; // Identificador para el thread pthread_attr_t attr; // Atributos de los threads DatosTemp val; // Parámetro del thread long periodo;

// Comprueba los parámetros

TestArg(argc, argv, &periodo); InicializarSignal(SIGNUM);

// Inicializa los parámetros de los threads por def ecto

pthread_attr_init (&attr); val.sig = SIGNUM; val.periodo = periodo;

// Crea el thread periodico

if (pthread_create (&th_id, &attr, ThreadPeriodico, ( void *)&val)!=0) {

perror( "Creando thread"); exit(-1);

}

// Espera un rato wait_t(periodo*NUM_PERIODOS);

// termina el thread periódico

if (pthread_cancel(th_id)!=0) perror("Cancelando thread");

else printf("Thread periódico, # %d, ha terminado\n",th_ id);

printf("Main thread, # %d termina\n", pthread_self( )); pthread_exit(NULL);

} /* *************************************************** ********* Thread peródico asignado al temprizador. Permite su cancelación *************************************************** ********* */ void * ThreadPeriodico( void *arg) {

timer_t temporizador; sigset_t sigset; // conjunto de sañales siginfo_t info; int sig; long periodo; int sigrecv; int cont =0; sig = (( DatosTemp *)arg)->sig; periodo = (( DatosTemp *)arg)->periodo; printf("Creado thread # %d, sig: %d, T: %ld\n", pthread_self(), sig, periodo);

// � Continua



12

// � Continuación // Inicializa el temporizador

if (InicializarTemporizador(periodo, sig, &temporizado r)!=0) pthread_exit(NULL);

// Permite la cancelación del thread pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL ); pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL) ; sigemptyset(&sigset); sigaddset(&sigset, sig); // define el conjunto para la espera

// Espera que llegue una señal (cualquiera) al thre ad while (1) {

sigwaitinfo(&sigset, &info); // Punto de cancelación if (info.si_signo == sig) //Comprueba si es la del temporizador {

// acción periódica printf("%d -> th # %d\n", cont++, pthread_self

()); }

} } /* *************************************************** ********* Inicializa la señal signum *************************************************** ********* */ int InicializarSignal( int signum) {

struct sigaction act; // manejador señal sigset_t sigset; // conjunto de sañales

// Bloquea la señal sigemptyset(&sigset); sigaddset(&sigset, signum); if (pthread_sigmask(SIG_BLOCK, &sigset, NULL)!=0) {

perror("Imposible bloquear la señal"); return -1;

}

/* Configura el manejador de la señal Necesario ya que el manejador por defecto termina el proceso completo al recib ir la señal*/

sigemptyset(&sigset); act.sa_sigaction = ManejadorSig; act.sa_mask = sigset; act.sa_flags = SA_SIGINFO; if(sigaction(signum, &act, NULL)<0) {

perror("Sigaction fallado"); return -1;

} return 0; } // � Continua



13

// � Continuación /* *************************************************** ********* Inicializa un temporizador periódico cada msec mili segundos asociado a la señal signum. El valor del temporizad or se devuelve en ptemp *************************************************** ********* */ int InicializarTemporizador( long msec, int signum, timer_t *ptemp) {

timespec_t periodo; struct sigevent evp; struct itimerspec param_temp; struct sigaction act; // manejador señal sigset_t sigset; // conjunto de sañales

// bloquea la señal sigemptyset(&sigset); sigaddset(&sigset, signum); if (pthread_sigmask(SIG_BLOCK, &sigset, NULL)!=0) {

perror("Imposible bloquear la señal"); return -1;

}

// Crea el temporizador evp.sigev_notify = SIGEV_SIGNAL; // tipo de notificación evp.sigev_signo = signum; // número de la señal evp.sigev_value.sival_int = 1; // Valor pasado al manejad de la señal

// El temporizador solo señaliza el thread que lo c rea if (timer_create(CLOCK_REALTIME, &evp, ptemp)!=0) {

perror("Error creando el temporizador"); return -1;

}

// Configura el temporizador periodo.tv_sec = msec/1000; periodo.tv_nsec = (msec%1000)*1000000L; param_temp.it_interval = periodo; // Valor cuando expira el temporizador (timespec_t) param_temp.it_value = periodo; // tiempo que queda para la expiración (timespec_t)

if (timer_settime(*ptemp, 0, &param_temp, NULL)!=0) {

perror("Error configurando el temporizador"); return -1;

} return 0;

} // � Continua



14

// � Continuación /* *************************************************** ********* Manejador de la Señal signo *************************************************** ********* */ void ManejadorSig( int signo, siginfo_t *info, void *context) { // no hace nada

printf("Soy el manejador de la señal # %d Valor: %d ", info->si_signo, info->si_value.sival_int);

printf("Code: (%d) ",info->si_code); if ( info->si_code == SI_USER)

printf("SI_USER \n" ); else if ( info->si_code == SI_TIMER )

printf("SI_TIMER \n" ); else if ( info->si_code == SI_QUEUE )

printf("SI_QUEUE \n" ); else if ( info->si_code == SI_ASYNCIO )

printf("SI_ASYNCIO \n" ); else if ( info->si_code == SI_MESGQ )

printf("SI_MESGQ \n" ); } /* *************************************************** ********* Comprueba los parámetros y asigna su valor *************************************************** ********* */ void TestArg( int argc, char *argv[], long *per) {

if (argc > 2) {

printf("Utilizar %s [periodo(ms)]\n", argv[0]); exit(0);

} if (argc==2)

*per = atol(argv[1]); else

*per = PER_DEF; // periodo por defecto } //Fin

1


1

SITR:Relojes POSIX

Indice

ü Vamos a estudiar mecanismos básicos para:

• Medir el paso del tiempo

• Retrasar la ejecución de una tarea durante un tiempo

• Establecer límites temporales para que ocurra un suceso

• Establecer relojes temporizados


2

SITR:Relojes POSIX

Medida del Paso del Tiempo

ü El tiempo es una magnitud física fundamental (unidad en el SI es el segundo)

ü Suele ser necesario realizar dos tipo sde medidas:û Intervalos de tiempoû Tiempo absoluto

ü Para medir valores absolutos de tiempo hace falta un sistema de referencia

ü Un sistema de referencia se basa en una escala de tiempo cuyo origen se denomina ‘época’

2


3

SITR:Relojes POSIX

Sistemas de Referencia

• Locales: el tiempo de arranque o creación del sistema.

• Astronómicos:

§ Tiempo universal. UT

§ Tiempo oficial: tiene en cuenta el huso horario y la corrección estacional

• Atómicos:

§ Tiempo atómico internacional

§ Tiempo universal coordinado


4

SITR:Relojes POSIX

Relojes POSIX

û La representación se realiza mediante:

• un número entero de segundos (32 bits)

• un número entero de nanosegundos (32 bits).

û La resolución es de 1 ns.

û El sistema de referencia utilizado para las medidas absolutas es el tiempo universal 1/1/1970 a las 0 horas.

û El intervalo máximo de medida es de 232 segundos es decir más de 136 años

û La granularidad depende de la implementación.

û No existe en POSIX una definición de intervalos de tiempo. Los intervalos de tiempo se miden por tanto por diferencia entre valores de reloj.

3


5

SITR:Relojes POSIX

Tipos de Relojes en POSIX

ü Reloj Calendarioû Proporciona valores de tiempo con resolución de 1s

ü Reloj de Tiempo Real:û Se pueden definir distintos relojesû Por lo menos debe haber uno denominado CLOCK_REALTIMEû La resolución de la representación es de 1nsû La granularidad depende de la implementación

ü Reloj de Tiempo Real Sytem Vû La resolución de la representación es de 1 microsegundos

ü Medida de tiempo de procesamiento.


6

SITR:Relojes POSIX

Reloj Calendario

ü Proporciona una medida de tiempo con una resolución de 1 segundo.

#include <time.h>

time_t time(time_t *tloc);

ü El tipo time_t es un entero de 32 bits

ü La función time() Devuelve el tiempo transcurrido en segundos desde las 0h del 1 de enero de 1970.

ü Si tloc no es NULL guarda también la hora en *tloc.

ü Conversión a unidades corrientes (año, mes dia, hora), teniendo en cuenta el tiempo oficial:

char * ctime(const time_t *clock);

4


7

SITR:Relojes POSIX

Reloj de Tiempo Real POSIX

ü El tiempo se representa mediante el la estructura timespec (<time.h>):

typedef struct timespec {

time_t tv_sec; /* segundos */

long tv_nsec; /* nanosegundos */

} timespec_t;

ü El tipo clockid_t (entero) que sirve para identificar los diferentes relojes.

ü Por lo menos debe estar definido un reloj que abarca a todo el sistema que se identifica como CLOCK_REALTIME

ü La resolución máxima del reloj suele ser de 20 ms

ü Puede haber otros relojes


8

SITR:Relojes POSIX

Reloj de Tiempo Real POSIX

• Leer el tiempo actual para el reloj clockid:

int clock_gettime(clockid_t clockid, struct timespec *tp);

• Poner en hora el reloj clockid :

int clock_settime(clockid_t clockid, const struct timespec *tp);

• Obtiene la resolución del reloj:

int clock_getres(clockid_t clockid, struct timespec *res);

5


9

SITR:Relojes POSIX

Reloj de Tiempo Real en SV

ü UNIX utiliza la estructura struct timeval para expresar el tiempo en microsegundos, definida en <sys/time.h>

struct timeval {

time_t tv_sec; /* segundos */

long tv_usec; /* microsegundos */

};

ü Leer el tiempo actual #include <sys/time.h>int gettimeofday(struct timeval *tp, void *tzp);

û Devuelve la hora en la estructura *tp (segundos y microsegundos).

û Si la función tiene éxito devuelve 0, de lo contrario devuelve –1.

û El apuntador tzp debe ser NULL.

ü Poner en hora el reloj :

int settimeofday(struct timeval *tp, void *tzp);


10

SITR:Relojes POSIX

Medida de Tiempo del Sistema

#include <sys/resource.h>int getrusage(int who, struct rusage * r_usage);

struct rusage {

struct timeval ru_utime; /* user time used */struct timeval ru_stime; /* system time used */

/*

..................

*/

};

6


11

SITR:Relojes POSIX

Retardos

ü Un retardo suspende la ejecución de un proceso durante un ciertotiempo.

ü Existen dos tipos de retardos:

• Retardo Relativo: la ejecución se suspende durante un intervalo de tiempo relativo al instante actual.

• Retardo Absoluto: la ejecución se suspende hasta que se llegue a un instante determinado de tiempo absoluto.


12

SITR:Relojes POSIX

Retardo Relativos

ü Las funciones para el manejo de retardos relativos en POSIX son dos:

#include <unistd.h>

#include <time.h>

unsigned int sleep(unsigned int seconds);

int nanosleep(const struct timespec *rqtp, struct timespec *rmtp);

ü La función sleep() suspende el proceso durante los segundos indicados.

ü La función nanosleep() permite un especificar retardos con una resolución de nanosegundos. La duración del retardo es *rqtp.

ü Si rqtp es distinto de NULL almacena la diferencia entre el tiempo especificado y el tiempo que el proceso ha estado dormido (este puede ser despertado por alguna señal)

7


13

SITR:Relojes POSIX

Retardos Absolutos

ü No existe en POSIX soporte directo para el manejo de retardos absolutos

ü Puede arpoximarse utilizando retardos relativos de la siguiente forma:

tiempo_actual = time ();

sleep(ret_absoluto-tiempo_actual);

ü Desde la lectura del tiempo actual hasta que se llama a la función sleep()el proceso puede haber sido expulsado de la CPU.

ü Para que fuera correcto, la lectura de tiempo y el cálculo deret_absoluto-tiempo_actual debería ser atómica.


14

SITR:Relojes POSIX

Retardo Efectivo

ü El valor especificado en un retardo no es exactamente el tiempo realmente esperado

Instrucción de retardo

El retardo termina aquí

Retardo especificado

Error degranularidad

Interrupción inhibida

Preparado Ejecución

tFigura 8.5 Tiempo de retardo efectivo

8


15

SITR:Relojes POSIX

Límites temporales (Time-outs)

ü A menudo conviene limitar el tiempo durante el cual se espera que ocurra un suceso.

ü Ejemplos:

û acceso a una sección crítica

û espera por un semáforo

û espera de una lectura desde un dispositivo físico (un puerto de comunicaciones por ejemplo) pueden producirse también situaciones de bloqueo.

ü POSIX incluye funciones para el manejo de temporizaciones asociadas a diferentes tipos de recursos.


16

SITR:Relojes POSIX

Límites temporales

ü Por ejemplo para el manejo de variables condicionales que permiten limitar el tiempo durante el cual se espera una condición se dispone de la siguiente función (el límite de tiempo es absoluto y su valor es *abstime)


int pthread_cond_timedwait( pthread_cond_t *cpnd, pthread_mutex_t *mutex,

const struct timeespec *abstime);

ü Para limitar el tiempo de espera de una señal se dispone de la siguiente función (timeout es un intervalo relativo):

#include <signal.h>

int sigtimedwait( const sigset_t *set, siginfo *info,


9


17

SITR:Relojes POSIX

Temporizadores (1)

ü Adicionalmente a las esperas temporizadas se pueden crear temporizadores asociados a relojes.

ü Están asociados al manejo de señales.

ü Cada temporizador se identifica mediante un valor de tipo timer_t, (entero) definido en la cabecera <time.h>.

ü El valor de espera se especifica mediante un valor de tipo itimerspec,cabecera <sys/time.h>:

struct itimerspec {

struct timespec it_interval; /* periodo */struct timespec it_value; /* expiración */

};


18

SITR:Relojes POSIX

Temporizadores (2)

ü Antes de usar un temporizador este debe ser creado mediante la siguiente función:

#include <signal.h>

#include <time.h>

int timer_create (clockid_t clock_id, struct sigevent *evp, timer_t *timerid)

ü Esta función crea un temporizador asociado al reloj clock_id (CLOCK_REALTIME).

ü *evp indica el tipo de notificación que se produce al expirar el temporizador (se trata de un manejador de señal).

ü El identificador del temporizador se devuelve en *timer_id.

10


19

SITR:Relojes POSIX

Temporizadores (3)

ü Una vez creado el temporizador debe ser activado especificando si debe ser absoluto o relativo y el valor inicial. Para ello se dispone de la función:

int timer_settime ( timer_t timerid, int flag,

const struct itimerspec *value, struct itimerspec *ovalue);

ü El tipo de temporización se selecciona con el parámetro flag.

ü El funcionamiento se repite periódicamente si value.it_interval >0.

ü En *ovalue se devuelve el valor que quedaba de la temporizaciónanterior.

ü El temporizador se destruye una vez que no sea necesario mediante la función:

int timer_delete ( timer_t timerid);


20

SITR:Relojes POSIX

Resumen Funciones POSIX (1)

TIPO DE DATOS CABECERA DESCRIPCIÓN

time_t <time.h> Entero 32 bits

struct timespec {time_t tv_sec; /* segundos */long tv_nsec; /* nanosegundos */

};

<time.h> Tiempo en nanosegundos

struct timeval {time_t tv_sec; /* segundos */long tv_usec; /* microsegundos */

};

<sys/time.h> Tiempo en microsegundos

clockid_t <time.h> Entero

struct rusage {struct timeval ru_utime;struct timeval ru_stime;/* ... */

};

<sys/time.h> Tiempo de uso de CPU

timer_t <time.h> Entero

struct itimerspec {struct timespec it_interval; /* periodo */struct timespec it_value; /* expiración */

};

<sys/time.h> Estructura de un temporizador

11


21

SITR:Relojes POSIX

Resumen Funciones POSIX (2)

F U N C I Ó N C A B E C E R A T I P O D EM E D I D A

D E S C R I P C I Ó N

t i m e _ t t i m e ( t i m e _ t * t l o c ) ; P O S I X / S V T i e m p o d e c a l e n d a r i o ( s e g u n d o s )

c h a r * c t i m e ( c o n s t t i m e _ t * c l o c k ) ;

< t i m e . h >

S V T i e m p o d e c a l e n d a r i o( f o r m a t e a d o )

i n t g e t t i m e o f d a y ( s t r u c t t i m e v a l * t p , v o i d* t z p ) ;

S V L e c t u r a d e t i e m p o e nm i c r o s e g u n d o s ( u s )

i n t s e t t i m e o f d a y ( s t r u c t t i m e v a l * , v o i d * ) ;

< s y s / t i m e . h >

S V P o n e r e n h o r a e l r e l o j ( u s )

i n t c l o c k _ g e t t i m e ( c l o c k i d _ t c l o c k i d , s t r u c tt i m e s p e c t p ) ;

P O S I X L e c t u r a d e t i e m p o e nn a n o s e g u n d o s ( n s )

i n t c l o c k _ s e t t i m e ( c l o c k i d _ t c l o c k i d , c o n s ts t r u c t t i m e s p e c t p ) ;

P O S I X P o n e r e n h o r a e l r e l o j ( n s )

i n t c l o c k _ g e t r e s ( c l o c k i d _ t c l o c k i d , s t r u c tt i m e s p e c r e s ) ;

< t i m e . h >

P O S I X O b e t i e n e l a r e s o l u c i ó n d e l r e l o j

i n t g e t r u s a g e ( i n t w h o , s t r u c t r u s a g e *r _ u s a g e ) ;

< s y s / r e s o u r ce . h >

S V T i e m p o d e u t i l i z a c i ó n d e C P U( u s )

u n s i g n e d i n t s l e e p ( u n s i g n e d i n t s e c o n d s ) ; P O S I X / S V R e t a r d o r e l a t i v o ( s e g u n d o s )

i n t n a n o s l e e p ( c o n s t s t r u c t t i m e s p e c * r q t p ,s t r u c t t i m e s p e c * r m t p ) ;

< t i m e . h >

P O S I X R e a t r d o r e l a t i v o ( n s )

i n t p t h r e a d _ c o n d _ t i m e d w a i t (p t h r e a d _ c o n d _ t * c p n d , p t h r e a d _ m u t e x _ t* m u t e x , c o n s t s t r u c t t i m e e s p e c * a b s t i m e ) ;

< p t h r e a d . h > P O S I X E s p e r a l i m i t a d a ( t i m e - o u t ) e nv a r i a b l e s c o n d i c i o n a l

i n t s i g t i m e d w a i t ( c o n s t s i g s e t _ t * s e t , s i g i n f o* i n f o , c o n s t s t r u c t t i m e s p e c * t i m e o u t ) ;

< s i g n a l . h > P O S I X E s p e r a l i m i t a d a ( t i m e - o u t ) e ns e ñ a l e s

i n t t i m e r _ c r e a t e ( c l o c k i d _ t c l o c k _ i d , s t r u c ts i g e v e n t * e v p , t i m e r _ t * t i m e r i d )

P O S I X C r e a u n t e m p o r i z a d o r

i n t t i m e r _ s e t t i m e ( t i m e r _ t t i m e r i d , i n t f l a g ,c o n s t s t r u c t i t i m e r s p e c * v a l u e , s t r u c ti t i m e r s p e c * o v a l u e ) ;

P O S I XA c t i v a u n t e m p o r i z a d o r

i n t t i m e r _ d e l e t e ( t i m e r _ t t i m e r i d ) ;

< s i g n a l . h >< t i m e . h >

P O S I X E l i m i n a u n t e m p o r i z a d o r

Ejemplo 1: uso de gettimeofday() #include <stdio.h> #include <math.h> #include <time.h> #include <sys/time.h> #define FIJAR_TMP() gettimeofday(&temp_1, 0) #define FIN_TMP() gettimeofday(&temp_2, 0) struct timeval temp_1, temp_2; void VER_TMP(char *txt) { if (txt!=NULL) fprintf(stderr, "\n %s\n", txt); fprintf(stderr, "Tiempo consumido real: %2.6f s\n", (temp_2.tv_sec-temp_1.tv_sec) + (float) (temp_2.tv_usec-temp_1.tv_usec)/1000000 ); } main() { int i; float sen; FIJAR_TMP(); for(i=0; i<10000; i++) sen=sin((float)i); FIN_TMP(); VER_TMP(“Ciclo for”); exit(0) }

Ejemplo 2: uso de clok_gettime() #include <stdio.h> #include <math.h> #include <time.h> #define FIJAR_TMP() clock_gettime(CLOCK_REALTIME, &temp_1) #define FIN_TMP() clock_gettime(CLOCK_REALTIME, &temp_2) struct timespec temp_1, temp_2; void VER_TMP(char *txt) { if (txt!=NULL) fprintf(stderr, "\n %s\n", txt); fprintf(stderr, "Tiempo consumido real: %2.9f s\n", (temp_2.tv_sec-temp_1.tv_sec)+ (float)(temp_2.tv_nsec-temp_1.tv_nsec)/1000000000 ); } main() { int i; float sen; FIJAR_TMP(); for(i=0; i<10000; i++) sen=sin((float)i); FIN_TMP(); VER_TMP(“Ciclo for”); exit(0) }

Ejemplo 3: uso de getrusage() #include <stdio.h> #include <math.h> #include <resource.h> #define FIJAR_RES() getrusage(RUSAGE_SELF, &utiliz_1) #define FIN_RES() getrusage(RUSAGE_SELF, &utiliz_2); struct rusage utiliz_1, utiliz_2; /*************************************************************** * Realiza una medida del tiempo consumido entre dos llamadas * Permite presentar también información de todos los recursos * consumidos. *****************************************************************/ void VER_RES(char *txt) { if (txt!=NULL) fprintf(stderr, "\n %s\n", txt); fprintf(stderr, "Tiempo consumido user: %2.6f s.\n", (utiliz_2.ru_utime.tv_sec-utiliz_1.ru_utime.tv_sec)+ (float) (utiliz_2.ru_utime.tv_usec- utiliz_1.ru_utime.tv_usec)/1000000 ); fprintf(stderr, "Tiempo consumido sys : %2.6f s.\n\n", (utiliz_2.ru_stime.tv_sec-utiliz_1.ru_stime.tv_sec)+ (float) (utiliz_2.ru_stime.tv_usec- utiliz_1.ru_stime.tv_usec)/1000000 ); } main() { int i; float sen; FIJAR_TMP(); for(i=0; i<10000; i++) sen=sin((float)i); FIN_TMP(); VER_TMP(“Ciclo for”); exit(0) }

Ejemplo 1: uso de gettimeofday() #include <stdio.h> #include <math.h> #include <time.h> #include <sys/time.h> #define FIJAR_TMP() gettimeofday(&temp_1, 0) #define FIN_TMP() gettimeofday(&temp_2, 0) struct timeval temp_1, temp_2; void VER_TMP(char *txt) { if (txt!=NULL) fprintf(stderr, "\n %s\n", txt); fprintf(stderr, "Tiempo consumido real: %2.6f s\n", (temp_2.tv_sec-temp_1.tv_sec) + (float) (temp_2.tv_usec-temp_1.tv_usec)/1000000 ); } main() { int i; float sen; FIJAR_TMP(); for(i=0; i<10000; i++) sen=sin((float)i); FIN_TMP(); VER_TMP(“Ciclo for”); exit(0) }

Ejemplo 2: uso de clok_gettime() #include <stdio.h> #include <math.h> #include <time.h> #define FIJAR_TMP() clock_gettime(CLOCK_REALTIME, &temp_1) #define FIN_TMP() clock_gettime(CLOCK_REALTIME, &temp_2) struct timespec temp_1, temp_2; void VER_TMP(char *txt) { if (txt!=NULL) fprintf(stderr, "\n %s\n", txt); fprintf(stderr, "Tiempo consumido real: %2.9f s\n", (temp_2.tv_sec-temp_1.tv_sec)+ (float)(temp_2.tv_nsec-temp_1.tv_nsec)/1000000000 ); } main() { int i; float sen; FIJAR_TMP(); for(i=0; i<10000; i++) sen=sin((float)i); FIN_TMP(); VER_TMP(“Ciclo for”); exit(0) }

Ejemplo 3: uso de getrusage() #include <stdio.h> #include <math.h> #include <resource.h> #define FIJAR_RES() getrusage(RUSAGE_SELF, &utiliz_1) #define FIN_RES() getrusage(RUSAGE_SELF, &utiliz_2); struct rusage utiliz_1, utiliz_2; /*************************************************************** * Realiza una medida del tiempo consumido entre dos llamadas * Permite presentar también información de todos los recursos * consumidos. *****************************************************************/ void VER_RES(char *txt) { if (txt!=NULL) fprintf(stderr, "\n %s\n", txt); fprintf(stderr, "Tiempo consumido user: %2.6f s.\n", (utiliz_2.ru_utime.tv_sec-utiliz_1.ru_utime.tv_sec)+ (float) (utiliz_2.ru_utime.tv_usec- utiliz_1.ru_utime.tv_usec)/1000000 ); fprintf(stderr, "Tiempo consumido sys : %2.6f s.\n\n", (utiliz_2.ru_stime.tv_sec-utiliz_1.ru_stime.tv_sec)+ (float) (utiliz_2.ru_stime.tv_usec- utiliz_1.ru_stime.tv_usec)/1000000 ); } main() { int i; float sen; FIJAR_TMP(); for(i=0; i<10000; i++) sen=sin((float)i); FIN_TMP(); VER_TMP(“Ciclo for”); exit(0) }

/* *********************************************************************

Manejo de temporizadores con ThreadsEjecución de tareas periódicas

Autor: Luis M. Jiménez Fecha: 12-1-00

**********************************************************************/

#define _REENTRANT

#include <stdio.h>#include <stdlib.h>#include <errno.h>#include <unistd.h>


#include <signal.h>#include "tiempo.h"

#define SIGNUM SIGRTMAX#define PER_DEF 1000L // 1s por defecto#define NUM_PERIODOS 10

typedef struct {int sig;long periodo;

} DatosTemp;

void TestArg(int argc, char *argv[], long *per);void * ThreadPeriodico(void *arg);int InicializarSignal(int signum);int InicializarTemporizador(long msec, int signum, timer_t *ptemp);void ManejadorSig( int signo, siginfo_t *info, void *context);

/* ****************************** función main *******************************/int main(int argc, char *argv[]){

pthread_t th_id; // identificador para el threadpthread_attr_t attr; // atributos de los threadsDatosTemp val; // parámetro del threadlong periodo;

// comprueba los parámetros TestArg(argc, argv, &periodo);

InicializarSignal(SIGNUM);

//inicializa los parámetros de los threads por defectopthread_attr_init (&attr);val.sig = SIGNUM;val.periodo = periodo;// crea el thread periodico

if(pthread_create (&th_id, &attr, ThreadPeriodico, (void *)&val)!=0)

{

perror( "Creando thread");exit(-1);

}

// espera un rato wait_t(periodo*NUM_PERIODOS);

// termina el thread periódico

if (pthread_cancel(th_id)!=0) perror("Cancelando thread");

else printf("Thread periódico, # %d, ha terminado\n",th_id);

printf("Main thread, # %d termina\n", pthread_self());

pthread_exit(NULL);}

/* ************************************************************ Thread peródico asignado al temprizador. Permite su cancelación *************************************************************/void * ThreadPeriodico(void *arg){

timer_t temporizador;sigset_t sigset; // conjunto de sañalessiginfo_t info;

int sig;long periodo;int sigrecv;int cont =0;

sig = ((DatosTemp*)arg)->sig;periodo = ((DatosTemp*)arg)->periodo;

printf("Creado thread # %d, sig: %d, T: %ld\n",pthread_self(), sig, periodo);

// Inicializa el temporizador if(InicializarTemporizador(periodo, sig, &temporizador)!=0)

pthread_exit(NULL);

// permite la cancelación del threadpthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL);

pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);

sigemptyset(&sigset); sigaddset(&sigset, sig); // define el conjunto para la espera

// espera que llegue una señal (cualquiera) al threadwhile(1){

sigwaitinfo(&sigset, &info); // punto de cancelaciónif(info.si_signo == sig) //comprueba si es la del

temporizador{

// acción periódicaprintf("%d -> th # %d\n", cont++, pthread_self

());}

} }

/* ************************************************************ Inicializa la señal signum *************************************************************/int InicializarSignal(int signum){

struct sigaction act; // manejador señalsigset_t sigset; // conjunto de sañales

// bloquea la señalsigemptyset(&sigset);

sigaddset(&sigset, signum); if(pthread_sigmask(SIG_BLOCK, &sigset, NULL)!=0) { perror("Imposible bloquear la señal"); return -1; }

// Configura el manejador de la señal// Necesario ya que el manejador por defecto termina el // proceso completo al recibir la señalsigemptyset(&sigset);act.sa_sigaction = ManejadorSig;act.sa_mask = sigset;act.sa_flags = SA_SIGINFO;

if(sigaction(signum, &act, NULL)<0){

perror("Sigaction fallado");return -1;

}

return 0;

}

/* ************************************************************ Inicializa un temporizador periódico cada msec milisegundos asociado a la señal signum. El valor del temporizador se devuelve en ptemp *************************************************************/int InicializarTemporizador(long msec, int signum, timer_t *ptemp){

timespec_t periodo;struct sigevent evp;struct itimerspec param_temp;struct sigaction act; // manejador señalsigset_t sigset; // conjunto de sañales

// bloquea la señalsigemptyset(&sigset);

sigaddset(&sigset, signum); if(pthread_sigmask(SIG_BLOCK, &sigset, NULL)!=0) { perror("Imposible bloquear la señal"); return -1; }

// Crea el temporizadorevp.sigev_notify = SIGEV_SIGNAL; // tipo de notificaciónevp.sigev_signo = signum; // número de la señalevp.sigev_value.sival_int = 1; // valor pasado al

manejador de la señal

// El temporizador solo señaliza el thread que lo creaif (timer_create(CLOCK_REALTIME, &evp, ptemp)!=0){

perror("Error creando el temporizador");return -1;

}

// Configura el temporizadorperiodo.tv_sec = msec/1000;periodo.tv_nsec = (msec%1000)*1000000L;param_temp.it_interval = periodo; // nuevo valor cuando

expira el temporizador (timespec_t)param_temp.it_value = periodo; // tiempo que queda

para la expiración (timespec_t)if (timer_settime(*ptemp, 0, &param_temp, NULL)!=0){

perror("Error configurando el temporizador");return -1;

}

return 0;}

/* ************************************************************ Manejador de la Señal signo *************************************************************/

void ManejadorSig( int signo, siginfo_t *info, void *context){

// no hace nada


printf("Code: (%d) ",info->si_code);if( info->si_code == SI_USER)

printf("SI_USER \n" );else if( info->si_code == SI_TIMER )

printf("SI_TIMER \n" );else if( info->si_code == SI_QUEUE )

printf("SI_QUEUE \n" );else if( info->si_code == SI_ASYNCIO )

printf("SI_ASYNCIO \n" );else if( info->si_code == SI_MESGQ )

printf("SI_MESGQ \n" );}

/* ************************************************************ Comprueba los parámetros y asigna su valor *************************************************************/void TestArg(int argc, char *argv[], long *per){ if(argc > 2) { printf("Utilizar %s [periodo(ms)]\n", argv[0]); exit(0); } if(argc==2)

*per = atol(argv[1]);else

*per = PER_DEF; // periodo por defecto

}

1. Sincronización.

1.1. Introducción.

Es necesario sincronizar el acceso a las zonas de memoria compartida con el fin de asegurar que los datos

compartidos mantengan su integridad para no dar lugar a una condición de carrera.

La seriabilidad dice que si se están ejecutando una serie de instrucciones de forma paralela, el resultado debe ser una

de las posibles alternativas secuenciales, por lo que si no se verifica la seriabilidad, se dice que se ha producido una

condición de carrera.

1.2. Ejemplo: Productor-Consumidor.

Este problema plantea la necesidad de comunicar la información por dos grupos de procesos: consumidores

(que son quienes necesitan la información) y productores (que son quienes la generan).

1.3. El Problema de la Sección Crítica.

En este problema se procura sistematizar el estudio de la sincronización. Sean n procesos compitiendo por

el uso de datos compartidos donde cada uno de ellos posee un segmento de código llamado sección crítica en la cual

se accede a los datos. La posible solución debe cumplir que:

• Exclusión mutua: si un proceso está ejecutando su sección crítica, ningún otro podrá ejecutarla.

• Progreso: Cuando existen varios procesos que quieren entrar en su sección crítica y modificar un dato

compartido, la decisión de quien es el que entra es un consenso entre todos.

• Espera limitada: un proceso no puede esperar indefinidamente a ejecutar la sección crítica.

1.4. Semáforos.

P (s)

� Decrementa el contador.

� Si el resultado es negativo, suspende al proceso que ha realizado la llamada y guardamos su PID en la cola.

V (s)

� Incrementa el contador.

� Si el valor es positivo o cero, despierta al primer proceso que se encuentra esperando en cola.

Ejemplo 1: Secuenciación de dos secciones de código de procesos diferentes. Pi: Pj: . . . . . . . . A P (s) V (s) B . . . . . . . . Ejemplo 2: Aparición de interbloqueos

P1 P2 . . . . . . . . P (S); P (Q); P (Q); P (S); . . . . . . . . V (S); V (Q); V (Q); V (S);

¿Dónde se ejecutan los

procesos?

¿Cómo se comunican los

procesos?

Mediante memoria compartida

En el mismo espacio de

direcciones o tienen acceso a

memoria común

Mediante la alteración de

variables globales

Mediante paso de mensajes En espacios de direcciones

independientes

Mediante el paso de mensajes de

uno a otro

Sistemas Informáticos en Tiempo Real Tema VII

Tema VII Sincronización y comu nicación

1

1. Sincronización. 1.1. Introducción.

En determinados problemas, es interesante que varios procesos se

ejecuten de forma independiente para colaborar en la resolución de dicho problema común. Este trabajo “en equipo” implica que exista comunicación entre procesos, puesto que todos ellos necesitan compartir determinados datos. Dicha comunicación puede ser:

• Mediante memoria compartida • Mediante paso de mensajes.

Las diferencias entre estos dos mecanismos de comunicación son:

¿Dónde se ejecutan los

procesos? ¿Cómo se comunican los

procesos?

Mediante memoria compartida

En el mismo espacio de direcciones o tienen acceso a

memoria común

Mediante la alteración de variables globales

Mediante paso de mensajes

En espacios de direcciones independientes

Mediante el paso de mensajes de uno a otro

En cualquier caso, es necesario sincronizar el acceso a las zonas de

memoria compartida con el fin de asegurar que los datos compartidos mantengan su integridad cuando varios procesos modifiquen su valor concurrentemente obteniéndose así, como resultado final, un dato no esperado por ningún proceso, algo conocido como condición de carrera.

El concepto de seriabilidad es interesante ya que se refiere a que si se

están ejecutando una serie de instrucciones de forma paralela, el resultado debe ser una de las posibles alternativas secuenciales, por lo que si no se verifica la seriabilidad, se dice que se ha producido una condición de carrera. Supongamos tres tareas que se ejecutan de forma paralela, entonces la seriabilidad dice que se puede obtener como resultado las seis siguientes posibilidades:

Figura 7.1. Ejemplo de 3! posibles soluciones

Tarea 1 Tarea 2 Tarea 3









2

1.2. Ejemplo: Productor-Consumidor.

Este problema plantea la necesidad de comunicar la información por dos

grupos de procesos: consumidores (que son quienes necesitan la información) y productores (que son quienes la generan).

En esta comunicación se emplea una zona de memoria de tamaño limitado (buffer) que almacena los datos producidos y los no producidos.

Figura 7.2. Los productores y consumidores se comunican por medio de una zona de memoria común

Puesto que varios procesos pueden acceder concurrentemente a una

zona de datos compartidos, debemos contemplar los siguientes aspectos:

• Este acceso concurrente puede provocar condiciones de carrera. • Debemos disponer de un mecanismo que asegure un orden correcto de

ejecución y así mantenga la integridad de los datos. • El productor debe esperar a que exista espacio libre en el buffer. • El consumidor debe esperar a que existan datos disponibles en el buffer.

Una posible implementación sería la siguiente:

. . . . . C P

BUFFER

type item=. . . . .; var buffer:array[0. .n-1] of item entrada, salida: 0. .n-1; contador: 0. .n in=0; out=0; contador=0; function productor;

repeat . . . . .

// produce un item en la variable nuevo . . . . . while contador==n do no-op (el buffer está lleno) buffer[entrada]=nuevo; entrada=(entrada+1)mod n contador=contador+1; until false end productor function consumidor; repeat while contador==0 do no-op (no hay objetos y no podemos consumir) nuevo=buffer[salida]; salida=(salida+1)mod n; contador=contador-1; . . . . . // consume el item almacenado en nuevo . . . . . until false end consumidor



3

Si examinamos la ejecución a bajo nivel de las operaciones sobre la variable contador descubriremos que es posible que se originen condiciones de carrera a pesar de que productor y consumidor actúan sobre zonas distintas del buffer. En el código del productor está la instrucción contador = contador + 1 que no es de ejecución atómica y equivale a: Se puede observar que no es una operación atómica puesto que se puede subdividir en tres operaciones. Por otra parte, en el código del consumidor se tiene la instrucción contador = contador -1 que equivale a: Se puede observar que no es una operación atómica puesto que se puede subdividir en tres operaciones. Buffer Salida Entrada Contador = 4

Figura 7.3. Esquema de implementación del problema de los productores - consumidores

mover contador al reg1 incrementar reg1 mover reg1 al contador

mover contador al reg2 decrementar reg2 mover reg2 al contador

Productores Consumidores

P2

C1

P1

mover contador al reg1 incrementar reg1 mover reg1 al contador

mover contador al reg2 decrementar reg2 mover reg2 al contador



4

Supongamos que la ejecución de dichas instrucciones es la siguiente:

TIEMPO PROCESO OPERACIÓN reg1 reg2 contador

t0 PRODUCTOR mov contador,reg1 5 ¿? 5 t1 PRODUCTOR inc reg1 6 ¿? 5 t2 CONSUMIDOR mov contador reg2 6 5 5 t3 CONSUMIDOR dec reg2 6 4 5 t4 PRODUCTOR mov reg1, contador 6 4 6 t5 CONSUMIDOR mov reg2, contador 6 4 4

A continuación mostraremos dicha ejecución sin interrupciones pudiendo mostrar así que el resultado no es el mismo debido a las inconsistencias originadas en la ejecución anterior. TIEMPO PROCESO OPERACIÓN reg1 reg2 contador t0 PRODUCTOR Mov contador,reg1 5 ¿? 5 t1 PRODUCTOR inc reg1 6 ¿? 5 t2 PRODUCTOR mov reg1, contador 6 ¿? 6 t3 CONSUMIDOR mov contador reg2 6 6 6 t4 CONSUMIDOR dec reg2 6 5 6 t5 CONSUMIDOR mov reg2, contador 6 5 5

Como conclusión podemos decir que, debido a que son operaciones no

atómicas, la variable contador es utilizada por el proceso consumidor y el consumidor desordenadamente provocando inconsistencias. 1.3. El Problema de la Sección Crítica.

En este problema se procura sistematizar el estudio de la sincronización. Sean n procesos compitiendo por el uso de datos compartidos donde cada uno de ellos posee un segmento de código llamado sección crítica en la cual se accede a los datos. Lo que se pretende es conseguir que ningún proceso pueda actuar sobre la sección crítica cuando otro proceso la está ejecutando, es decir, cuando un proceso actúe sobre un dato compartido ningún otro podrá modificarlo.

Vuelve a producirse un cambio de contexto dando lugar a un cambio de estado entre productor y consumidor.

Da la casualidad de que se produce un cambio de contexto y en el próximo instante, en vez de volver a actuar el productor entra a trabajar el consumidor.

Sección de entrada

Sección

crítica

Sección de salida

Figura 7.4. Sección crítica

Sección restante



5

Nosotros emplearemos una especie de “candado” que cerraremos cuando un proceso ejecute la sección crítica de modo que ningún otro ejecute dicho código mientras el “candado” esté cerrado (sección de entrada). Cuando dicho proceso termine de ejecutar la sección crítica, entonces abriremos el “candado” para que dicho código quede libre para otros procesos (sección de salida).

Para resolver el problema de la sección crítica hay que definir el código de la sección de entrada y de salida. La posible solución debe cumplir que:

• Exclusión mutua: si un proceso está ejecutando su sección crítica, ningún otro podrá ejecutarla.

• Progreso: Cuando existen varios procesos que quieren entrar en su

sección crítica y modificar un dato compartido, la decisión de quien es el que entra es un consenso entre todos.

• Espera limitada: un proceso no puede esperar indefinidamente a ejecutar

la sección crítica. Existen dos soluciones para solventar este problema: Inhibición de interrupciones Solución Hardware Instrucción Test_and_set atómica Instrucción swap atómica Solución Software Semáforos 1.4. Semáforos. 1.4.1. Características: Operaciones P y V. Un semáforo es una estructura formada por dos miembros: una variable de tipo entero y una cola de procesos en espera. A un semáforo sólo se puede acceder mediante dos vías: P y V. Una posible definición de semáforo es:

typedef semáforo { int contador; cola: lista de procesos; }



6

Veamos que hace cada una de las operaciones:

• P (s) � Decrementa el contador. � Si el resultado es negativo, suspende al proceso que ha realizado la llamada y guardamos su PID en la cola asociada al semáforo.

• V (s) � Incrementa el contador. � Si el valor es positivo o cero, despierta al primer proceso que se encuentra esperando en cola.

El significado del valor del contador es el siguiente:

• Si el contador es mayor que cero, éste indica el número de procesos que pueden invocar P sin suspenderse.

• Si el contador es negativo, el módulo de éste indica el número de

procesos suspendidos. Es importante recalcar que, usando semáforos, no existe espera activa por lo que no existe gasto innecesario de tiempo de CPU y que, además, el Sistema Operativo debe asegurarse de que las operaciones P y V se realicen de forma atómica.

1.4.2. Problema de la sección crítica. Para solucionar este problema se opta por definir un semáforo común a todos los procesos

S.contador = S. contador – 1; if (S.contador < 0) { Insertar_en_cola (S.cola, Proceso_en_ejecución); Suspender (Proceso_en_ejecución); }

S.contador = S. contador + 1; if (s.contador >= 0) { Extraer_de_cola (S.cola, Proceso); Activar (Proceso); }

var mutex: semáforo (1) \* El valor inicial del con tador es -1*\



7

A este tipo de semáforos se les suele llamar mutex ya que se utilizan para asegurar la exclusión mutua. Cada proceso Pi tiene la estructura siguiente:

Figura 7.5. Solución al problema de la Sección Crítica

1.4.3. Uso de semáforos.

Ejemplo 1: Secuenciación de dos secciones de código de procesos diferentes. Se pretende ejecutar B en Pj después de A en Pi. La solución consiste en definir un semáforo S con valor inicial del contador cero (S.contador = 0) y se definen las secuencias de instrucciones de Pi y Pj como se muestra a continuación: Pi: Pj: . . . . . . . . A P (s) V (s) B . . . . . . . . Ejemplo 2: Aparición de interbloqueos Al emplear semáforos es posible que nadie pueda acceder a su sección crítica debido a que todos los procesos que comparten el semáforo están suspendidos. Imaginemos que tenemos dos procesos P1 y P2, los cuales comparten dos semáforos S y Q cuyos contadores están inicialmente a 1. Si ambos ejecutan la siguiente secuencia

P1 P2 . . . . . . . . P (S); P (Q); P (Q); P (S); . . . . . . . . V (S); V (Q); V (Q); V (S);

.

.

. P (mutex); sección crítica V (mutex); . . .

Cuando llegamos a esta línea de código decrementaremos el valor del mutex para que ningún otro proceso actúe sobre la sección crítica

Después, al finalizar emplearemos la operación V para “liberarlo”.



8

Si ahora se produce la siguiente secuencia de ejecución: P2: P (q) P1: P (s) P2: P (q) (se suspende) P1: P (s) (se suspende)

Ambos procesos están suspendidos esperando a que el otro realice una operación V que nunca se producirá porque los procesos están suspendidos.

1.4.4. Construcciones lingüísticas.

Para evitar los errores originados por la incorrecta utilización de los semáforos (generando así errores de sincronización), se han diseñado construcciones lingüísticas de alto nivel que simplifican la programación de aplicaciones concurrentes. Tipos de construcciones:

• Construcciones teóricas.

- Monitores - Regiones críticas.

• Construcciones de uso práctico.

- Tipos de protegidos en ADA 95. - Objetos de sincronización en JAVA.

1.4.5. Sincronización de Threads. POSIX.1C posee un mecanismo de sincronización de threads llamado mutex para el uso de semáforos a corto plazo y que maneja variables de condición para expresar sucesos de duración limitada. El mutex es el mecanismo de sincronización más sencillo y más eficiente. Los programas empelan mutex para obtener acceso exclusivo a las variables o a los recursos. Un mutex no es más que una variable de tipo pthread_mutex_t (que es una estructura invisible para el usuario y almacena toda la información referente al mutex). Las funciones que aporta POSIX.1C para la creación y manejo de mutex son:

Función Descripción pthread_mutex_init Inicializa una variable de tipo pthread_mutex_t pthread_mutex_destroy Destruye una variable mutex pthread_mutex_lock Protege la sección crítica (operación P) pthread_mutex_unlock Libera la protección de la sección crítica (op. V) pthread_mutex_trylock Como pthread_mutex_lock pero sin bloqueo

Tabla 7.1. Funciones básicas para el manejo de mutexes



9

Veamos cada una de las funciones:

• pthread_mutex_init(): Esta función inicializada una variable mutex de tipo pthread_mutex_t. Su sintaxis es:

Se puede apreciar que esta función tiene dos parámetros:

• Un puntero a una variable de tipo pthread_mutex_t. • Un objeto atributo del cual podemos obtener y modificar sus miembros.

Generalmente pondremos como último parámetro NULL para usar un objeto atributo por defecto.

Un ejemplo de inicialización de una variable mutex con los atributos por defecto es:

• Pthread_mutex_destroy():

Éste destruye la variable mutex. Se puede observar que el mutex no se destruye realmente hasta que queda completamente libre. Su sintaxis es:

• pthread_mutex_lock():

Ésta es la equivalente a la operación P en semáforos. Cuando un thread ejecuta esta función antes de su sección crítica, entra en ella sólo si no hay ningún otro thread que use el mismo mutex para ejecutar con exclusión mutua la suya. Si el mutex está cerrado, el thread que invoca esta llamada se suspende hasta que el mutex sea liberado. Su sintaxis es:


int pthread_mutex_init ( pthread_mutex_t * mutex, const pthread_mutex_attr_t *att);

#include <phtread.h>

int pthread_mutex_destroy ( pthread_mutex_t * mutex);


int pthread_mutex_lock ( pthread_mutex_t *mutex);

#include <pthread.h> pthread_mutex_t my_lock; if (!pthread_mutex_init (&my_lock, NULL)) perror (“no puedo inicializar my_lock”);



10

• pthread_mutex_unlock():

Esta es equivalente a la operación V de semáforos. Se libera el mutex cuando un thread termina de ejecutar su sección crítica. En el caso de que exista algún thread suspendido en la cola asociada al mutex, esta función activa al primero de la lista. Veamos un ejemplo donde se emplea un mutex para proteger una sección crítica.

• pthread_mutex_trylock():

Es igual que pthread_mutex_lock() pero si el candado está cerrado no bloquea al proceso llamante, simplemente devuelve un valor distinto de cero. Su sintaxis es:

Veamos un ejemplo: Ejemplo 3.

Se desea resolver el problema de los productores consumidores mediante threads. Para ello se utilizará un buffer de tamaño 12 cuyo funcionamiento se basa en la gráfica siguiente: Buffer Entrada Salida

Contador = 4

Figura 7.4. Esquema de la solución para el problema productor – consumidor

#include <pthread.h> pthread_mutex_t my_lock; pthread_mutex_init(&mylock, NULL); (ni por defecto) pthread_mutex_lock(&my_lock); /* Sección crítica */ (no puede entrar threads simultáneamente) pthread_mutex_unlock(&my_lock);


P2

C1 P1


int pthread_mutex_trylock ( pthread_mutex_t *mutex);



11

La variable salida indica el número de ranura del siguiente elemento que se va a sacar, y el valor entrada indica la siguiente la ranura que se llenará. Si los productores y consumidores no actualizan entrada y salida de forma mutuamente exclusiva (atómica) un productor podría sobrescribir un elemento que no ha sido sacado o un consumidor podría sacar un elemento que ya se ha sacado.

1.7. Sincronización de procesos. 1.7.1. Semáforos POSIX.

Un semáforo POSIX (perteneciente al estándar POSIX.1b y relativamente reciente) es una variable de tipo sem_t a la cual se pueden aplicar operaciones atómicas como inicialización, incremento (V), decremento (P),...

El estándar POSIX define dos tipos de semáforos:

• Semáforos no nombrados: Este semáforo se caracteriza por poder usarse

únicamente por un proceso y por toda su descendencia. • Semáforos nombrados: Éste, en cambio, puede ser utilizado por

cualquier proceso aunque este proceso no tenga ningún tipo de relación con el proceso que crea el semáforo.

La declaración de un semáforo POSIX (ya sea nombrado o no nombrado)

se realiza con el siguiente código:

#include <pthread.h> #define BUFSIZE 12 static int buffer[BUFSIZE] static int entrada = 0; static int salida = 0; static pthread_mutex_t candado = PTHREAD_MUTEX_INITIALIZER; /*Obtener el siguiente elemento del buffer y coloca rlo en itemp */ void get_item( int *itemp) { pthread_mutex_lock (&candado); /*esto es para asegurarnos que ningún thread

entra. Protegemos el acceso a la variable salida.*/ *itemp = buffer(salida): contador = contador – 1; salida = (salida + 1) % BUFSIZE; pthread_mutex_unlock(&candado); return; } /* Colocar un elemento en el buffer */ void get_item ( int item) { pthread_mutex_lock(&candado) buffer[entrada] = item; entrada = (entrada + 1) % BUFSIZE; pthread_mutex_unlock(&candado); return ; }



12

Es conocido que una variable de tipo sem_t almacena toda la información referente al semáforo por lo que esto implica que POSIX no especifica la naturaleza del tipo sem_t.

La mayor diferencia entre semáforos nombrados y no nombrados es la

forma de crear e inicializar el semáforo. Otra característica interesante de los semáforos POSIX es que son semáforos contadores que tienen valores no negativos y deben ser inicializados antes de usarlos.

Una llamada al sistema para creación o manipulación de semáforos

devuelve el valor 1 en caso de error y 0, generalmente, en caso de éxito. 1.7.2. Operaciones con semáforos POSIX.

A continuación estudiaremos las funciones asociadas a la creación y manipulación de los dos tipos de semáforos POSIX: Semáforos no nombrados

Puesto que este tipo de semáforos deben inicializarse antes de ser usados, necesitamos una función que los inicialice: sem_init(). Su sintaxis es la siguiente:

Los distintos parámetros junto con sus explicaciones son:

- sem: El semáforo que queremos inicializar. - value: Se trata de un parámetro necesariamente no negativo y que hace

referencia al número de procesos que pueden acceder simultáneamente al recurso asociado al semáforo.

- pshared: Se trata de un argumento cuyo valor va a determinar el uso del semáforo por el proceso o por éste junto con su descendencia:

Si pshared vale 0, entonces el semáforo sólo puede ser

usado por el proceso que lo ha creado. Si pshared no vale 0, entonces el semáforo puede ser

empleado por cualquier proceso pariente del creador. Las funciones que manipulan semáforos nombrados son:

#include <semaphore.h> sem_t semáforo;

int sem_init ( sem_t *sem, int pshared, unsigned int value);



13

Función Descripción sem_destroy Elimina un semáforo sem_wait Operación espera de semáforo (P) sem_trywait Sem_wait() sin bloqueo sem_post Libera el semáforo (V) sem_getvalue Examina el valor de un semáforo

Tabla 7.2. Funciones de manipulación de semáforos nombrados

• Sem_destroy(): Destruye un semáforo previamente inicializado. Su sintaxis es:

Si un proceso intenta destruir un semáforo que tiene un proceso en espera, sem_destroy() devuelve un mensaje de error.

• Sem_wait():

Con esta fusión conseguiremos decrementar el valor del contador del semáforo (operación P). La sintaxis de esta llamada es la siguiente: Si el valor del semáforo es cero, entonces sem_wait efectúa un bloqueo del proceso invocante (al decrementar el contador obtenemos el valor negativo -1). Hasta que no se incrementa el contador el recurso gestionado por el semáforo no quedará libre.

• Sem_trywait(): Es similar a la anterior, pero en lugar de bloquear el proceso invocante cuando el valor del semáforo es 0, no hace nada y devuelve 1. Su sintaxis es:

• Sem_post(): Esta función incrementa el valor del semáforo (operación V). Su sintaxis es la siguiente:

• Sem_getvalue(): Permite examinar el valor de un semáforo. Su sintaxis es:

#include <semaphore.h> int sem_destroy ( sem_t *sem);

#include <semaphore.h> int sem_wait ( sem_t *sem);

#include <semaphore.h> int sem_trywait ( sem_t *sem);

#include <semaphore.h> int sem_post ( sem_t *sem);



14

El parámetro sval lo usaremos para poner el valor actual del semáforo sem. sval será dicho valor actual. Esta función devuelve 1 en caso de error o 0 si ha tenido éxito. Ejemplo 4. Semáforos nombrados:

Con estos semáforos seremos capaces de sincronizar procesos que no tienen ninguna relación entre sí. Los semáforos nombrados poseen:

- Nombre. - Identificador de usuario. - Identificador de grupo. - Permisos de acceso.

El nombre de un semáforo es una cadena de caracteres que cumple los

mismos requisitos que un nombre de archivo. Además,

- Si el nombre comienza por “/”, el semáforo puede ser compartido por cualquier proceso.

#include <semaphore.h> int sem_getvalue ( sem_t *sem, int *sval);



15

- Si la ruta es relativa, solo puede acceder al semáforo el proceso que lo

crea. En la siguiente tabla se muestran las funciones para trabajar con

semáforos nombrados: Función Descripción

sem_destroy Elimina un semáforo sem_wait Operación espera de semáforo (P) sem_trywait Sem_wait sin bloqueo sem_post Libera el semáforo sem_getvalue Examina el valor de un semáforo sem_open Crea o establece la conexión entre un semáforo nombrado y su proceso sem_close Desvincula a un proceso de un semáforo sem_unlink Elimina un semáforo nombrado del sistema

Tabla 7.2. Funciones de manipulación de semáforos no nombrados

Veamos cada uno de las llamadas:

• Sem_destroy(): Destruye un semáforo previamente inicializado. Su sintaxis es:

Si un proceso intenta destruir un semáforo que tiene un proceso en espera, sem_destroy () devuelve un mensaje de error.

• Sem_wait():

Con esta fusión conseguiremos decrementar el valor del contador del semáforo (operación P). La sintaxis de esta llamada es la siguiente: Si el valor del semáforo es cero, entonces sem_wait() efectúa un bloqueo del proceso invocante (al decrementar el contador obtenemos el valor negativo -1). Hasta que no se incrementa el contador el recurso gestionado por el semáforo no quedará libre.

• Sem_trywait(): Es similar a la anterior, pero en lugar de bloquear el proceso invocante cuando el valor del semáforo es 0, no hace nada y devuelve 1. Su sintaxis es:

#include <semaphore.h> int sem_destroy ( sem_t *sem);

#include <semaphore.h> int sem_wait ( sem_t *sem);

#include <semaphore.h> int sem_trywait ( sem_t *sem);



16

• Sem_post(): Esta función incrementa el valor del semáforo (operación V). Su sintaxis es la siguiente:

• Sem_getvalue(): Permite examinar el valor de un semáforo. Su sintaxis es: El parámetro sval lo usaremos para poner el valor actual del semáforo sem. sval será dicho valor actual. Esta función devuelve 1 en caso de error o 0 si ha tenido éxito.

• Sem_open(): Esta función devuelve un valor que es utilizado por sem_wait(), sem_trywait(), sem_destroy(), sem_getvalue() para referirse a dicho semáforo. Su sintaxis es:

Los parámetros son:

- oflag: Determina si el semáforo accede a un semáforo previamente

creado o lo crea. Si oflag es 0 significa que se quiere acceder a un semáforo ya creado, mientras que si oflag tiene un valor de 0_CREART o O-CREAT / O-EXELL, sem_open() requiere la segunda sintaxis. Las dos etiquetas oflag funcionan de la siguiente forma:

- O_CREART: sem_open() crea un semáforo si no

existe. Si ya existe un semáforo e ignora el tercer y cuarto argumentos.

- O_CREART / O_EXECL: sem_open() crea un

semáforo si no existe. Si ya existe un semáforo con dicho nombre, la función devuelve -1.

- mode: Especifica los permisos que se crea al semáforo.

#include <semaphore.h> sem_t * sem_open ( const char *name, i nt oflag); sem_t * sem_open ( const char *name, int oflag, mode_t mode,

unsigned int value);

#include <semaphore.h> int sem_post ( sem_t *sem);

#include <semaphore.h> int sem_getvalue ( sem_t *sem, int *sval);



17

- value: Especifica el valor inicial del semáforo creado.

• Sem_close():

Se llama a esta función para liberar los recursos del sistema que fueron

asignados al proceso por trabajar con el semáforo. Su sintaxis es: Esta función vuelve al semáforo inaccesible para el proceso.

• Sem_unlink(): Elimina un semáforo nombrado del sistema. Su sintaxis es: Si otros procesos hacen referencia al semáforo sem, la llamada sem_unlink() propone la distribución hasta que todas las referencias sean cerradas por sem_close(). Las llamadas sem_open() con el mismo nombre de semáforo, se refieren a un nuevo semáforo después de haber ejecutado una llamada sem_unlink() aun cuando algunos procesos tengan todavía ese semáforo abierto. 2. Comunicación. 2.1. Comunicación entre procesos Para permitir la comunicación entre procesos que desean cooperar hay dos modelos de comunicación entre procesos:

• Memoria compartida:

Los procesos comunicantes comparten información mediante algunas variables. En este modelo, los procesos tienen un espacio de memoria en común y la responsabilidad de proporcionar dicha comunicación recae sobre el programador. El sistema operativo sólo proporciona la memoria compartida.

• Paso de mensajes:

En éste, los procesos intercambian mensajes. Los procesos tienen

espacios de direcciones independientes y, puesto que el sistema operativo

#include <semaphore.h> int sem_close ( sem_t * sem);

#include <semaphore.h> int sem_unlink ( sem_t * sem);



18

proporciona las operaciones básicas de comunicación, es el sistema el que proporciona la comunicación.

send (destino, mensaje)

recieve (origen, mensaje)

Puesto que es necesario definir las características de los enlaces de comunicación, a continuación se citan cada una de ellas:

a) Modo de nombrar origen y destino:

Los procesos deben tener una forma para referirse entre ellos mismos y para ello pueden utilizar una de las dos comunicaciones siguientes:

• Comunicación directa:

En esta, los procesos necesitan conocer el PID de aquellos procesos con los que intercambian mensajes ya que send (proceso-destino-msj) y recieve (proceso-origen-msj) requieren un identificador para operar. Las propiedades más importantes son:

- Se establece un canal único entre los procesos que se comunican. - Dicho canal suele ser bidireccional. - Utilizando la operación recieve (ANY, msj) se tiene una variante en la

que el proceso puede recibir de cualquier otro. Ejemplo 5. Solución al problema productor-consumidor. Veamos la implementación de problema del productor - consumidor. function productor; function consumidor; var item: elem; var item: elem; repeat repeat

Item = producir(); receive (productor, item) send (consumidor, item); comsumir (item);

until false; until false; end productor; end consumidor;

• Comunicación indirecta:

Los mensajes se “mueven” a través de entidades lógicas que tienen un

identificador único en el sistema. Estos puertos (o ports) no son más que un lugar de almacenamiento y lectura de mensajes con un único identificador (los puertos son anónimos). Sabemos que varios procesos pueden recibir y enviar al mismo puerto (pero lo habitual es que sólo uno reciba) y, además, dos procesos pueden compartir más de un puerto. Existen varias alternativas en la posesión del puerto:



19

- El puerto pertenece a un proceso: un proceso declara un puerto y es el

único que puede recibir del mismo. Es necesario disponer de operaciones de creación y destrucción de un puerto.

- El puerto pertenece al sistema operativo: cualquier proceso lo puede utilizar. Además de las operaciones send() y recieve(), se necesita la operación blind() que asocia el puerto a un proceso.

- Cuando varios procesos pueden recibir de un puerto, se necesita un protocolo de comunicación.

Dentro de este tipo de comunicación se define el modelo CLIENTE

SERVIDOR.

Éste consiste en que cada recurso del sistema que se desee compartir

tiene asociado un proceso servidor. Éste recibe las peticiones de uso de los clientes en un puerto, las ejecuta por ellos y devuelve una respuesta. Los clientes deben solicitar dichas peticiones enviando un mensaje al puerto adecuado y esperar la respuesta. Este modelo permite que el cliente y el servidor residan en máquinas distintas.

El código básico del modelo CLENTE-SERVIDOR es:

CLIENTE SERVIDOR . . . repeat send (port, petición); receive (port, petición); receive (myport, respuesta); respuesta = hacer(petición); . . . ret = remitente (petición); send (ret, respuesta); until false;

b) Capacidad de enlace.

Respuesta

Petición

Nodo cliente Nodo servidor

Port



20

Se trata de la capacidad de almacenamiento de mensajes en el canal, es decir, la capacidad de mensajes que pueden permanecer en el puerto sin ser leídos.

• Capacidad nula:

En este caso, a la comunicación se le denomina síncrona y sólo se lleva a

cabo cuando el proceso emisor y receptor ha invocado las operaciones de enviar y recibir. Los procesos se sincronizan según el modelo de Rendez vous:

“El primer proceso que llega a la cita siempre se bloquea tal y como se muestra en la figura”.

• Capacidad no nula:

Ésta es una comunicación asíncrona. En este caso pueden darse dos posibles situaciones:

- Canal con una capacidad limitada. - Canal con una capacidad ilimitada.

La sincronización de la comunicación asíncrona se realiza de la siguiente

manera:

- Una operación recieve() de un canal vacío suspende al proceso invocante.

- Una operación send() con un canal lleno puede:

send susp. recv

P1 P2 Recv. susp. send

P1 P2



21

• Suspender al proceso invocante. • Perder el mensaje. • Devolver un mensaje de error.

- Para notificar la lectura de un mensaje y así poder simular un sistema

síncrono, se usan mensajes de reconocimiento ACK:

P Q

send (Q, mensaje) recieve (P, mensaje) recieve (Q, ACK) send (P, ACK)

- En enlaces de capacidad limitada, cuando los productores son muy rápidos, es posible desbordar la capacidad del enlace y es necesario utilizar un protocolo de control de flujo para reducir la velocidad de los productores.

- En comunicaciones asíncronas no se garantiza el orden correcto de los mensajes recibidos y es necesario adoptar un protocolo para asegurar el orden.

c) Modo de establecer la conexión.

Los modos de conexión pueden ser:

- Sin conexión (similar al correo): El mensaje o datagrama se deposita en un recipiente.

- Con conexión (similar al teléfono): Se usan circuitos virtuales de modo que el que envía y el que recibe están bien conectados.

d) Cantidad de procesos asociados al canal.

Un canal puede tener varios procesos asociados, no exclusivamente dos, el que envía y el que recibe.

e) Cantidad de canales entre cada par de procesos.

La comunicación entre dos procesos (situación más normal) puede tener asociada más de un canal (por ejemplo dos canales, uno para enviar/recibir instrucciones a ejecutar y otro para enviar/recibir datos).

f) Tipo de comunicación.

El tipo de comunicación puede ser unidireccional, donde en el caso de dos procesos, uno sólo envía y otro sólo recibe, o bien bidireccional donde ambos pueden recibir o enviar.

g) Talla de los mensajes.



22

Los mensajes asociados a una conexión pueden ser de talla fija o talla variable.

?1


1

Sincronización Sincronización y Comunicación (I)

? Sistema multiprogramado ? procesos concurrentes cooperantes

? Datos de un proceso Pi deben ser conocidos por el proceso Pj

? Formas de comunicación

? Mediante memoria compartida• Los procesos se ejecutan en el mismo espacio de direcciones (threads) o tienen

acceso a memoria común.• Se comunican mediante variables globales

? Mediante paso de mensajes• Los procesos se pueden ejecutar en espacios de direcciones independientes• Se comunican mediante mensajes• La infraestructura de la comunicación la ofrece el SO (ports, pipes, ...)


2

Sincronización Sincronización y Comunicación (II)

? Es necesario sincronizar el acceso a zonas de memoria compartida para mantener la integridad de los datos

? Un dato puede perder la integridad cuando varios procesos lo modifican concurrentemente

? Seriabilidad: la ejecución paralela de un conjunto de instrucciones debe ser equivalente a la de una de las posibles alternativas secuenciales

? Si no se cumple la seriabilidad se dice que se ha producido una condición de carrera

?2


3

Sincronización Ejemplo: Productor - Consumidor (I)

? Se plantea la necesidad de comunicar la información generada por un grupo de procesos (productores) a otro grupo que necesitan de ella (consumidores)

? En la comunicación se utiliza una zona de memoria de tamaño limitado (buffer) que almacena los datos producidos y no consumidos

? El problema consiste en que varios procesos acceden concurrentemente a una zona de datos compartidos y se pueden dar condiciones de carrera

P C.....

Buffer


4

Sincronización Ejemplo: Productor - Consumidor (II)

? contador = contador +1

? contador = contador - 1

mov contador, reg1inc reg1mov reg1, contador

mov contador, reg1inc reg1mov reg1, contador


Entrada

Salida

P1

C1

P2

Contador = 4

Buffer

?3


5

Sincronización Ejemplo: Productor - Consumidor (III)

? Supongamos que se da la siguiente ejecución

? La variable contador es utilizada por el proceso consumidor antes de que el proceso productor la actualice ? inconsistencia (vale 4 en vez de 5)

? CONCLUSION: este tipo de operaciones deben ser ATOMICAS

Tiempo Proceso Operación reg1 reg2 contador

t0 productor mov contador, reg1 5 ? 5

t1 productor inc reg1 6 ? 5

t2 consumidor mov contador, reg2 6 5 5

t3 consumidor dec reg2 6 4 5

t4 productor mov reg1, contador 6 4 6

t5 consumidor mov reg2, contador 6 4 4


6

Sincronización El Problema de la Sección Crítica (I)

? Intenta sistematizar el estudio de la sincronización

? Sean n procesos que tienen datos compartidos. Cada proceso tiene un segmento de código llamado Sección Crítica en el cual se accede a los datos

? Se pretende que cuando un proceso está en su sección crítica, ningún otro este en la suya propia

Sección de Entrada

Sección de Salida

SECCIONCRITICA

Sección restante

?4


7

Sincronización El Problema de la Sección Crítica (II)

? Para resolver el problema de la sección crítica hay que definir el código de la sección de entrada y de la sección de salida

? Una solución al problema de la sección crítica debe cumplir las siguientes propiedades

? Exclusión mutua: si Pi ejecuta su sección crítica, ningún otro Pj (i? j) lo podrá hacer en la suya

? Progreso: Si no hay procesos ejecutando su sección crítica y hay varios que quieren entrar en la suya, la decisión de quien entra la deben tomar aquellos que no se encuentre en su sección restante y en un tiempo finito

? Espera limitada: Un proceso no debe esperar infinitamente a ejecutar su sección crítica

? El problema de la sección crítica se puede resolver son soluciones software o hardware


8

Sincronización El Problema de la Sección Crítica (III)

? Soluciones hardware? Inhibición de interrupciones

• La forma más sencilla y menos eficiente de resolver el problema• No se permiten interrupciones durante la ejecución de la sección crítica (así se evitan

los cambios de contexto)

• Sólo es útil cuando la sección crítica es pequeña• Este método de sincronización sólo es aplicable a nivel del SO (es peligroso que los

usuarios accedan al sistema de interrupciones)

Inhibir_Interrupciones();Sección críticaHabilitar Interrupciones();

?5


9

Sincronización El Problema de la Sección Crítica (IV)

? Instrucción Test_and_Set atómica• Consiste en evaluar y asignar de forma atómica una variable lógica• Test_and_Set pertenece al juego de instrucciones del procesador

• Algoritmo que satisface la exclusión mutua

boolean Test_and_Set (boolean objetivo){

Test_and_Set = objetivo;objetivo = true;

}

/*Variables globales o datos compartidos*/var llave: boolean (*Inicialmente a false*)

Proceso Pirepeat

while Test_and_Set(llave) do no-op;Sección críticallave = false;sección restante;

until false

Utiliza un bucle de espera activa (consume CPU para nada)


10

Sincronización El Problema de la Sección Crítica (V)

? Instrucción swap atómica• Permite intercambiar de forma atómica el contenido de dos variables (el contenido de

un registro por el de una posición de memoria)

void swap(register r, memory m)int temp;{

temp = m;m = r;r = temp;

}

/* Algoritmo que satisface la exclusión mutua*/(* cerrojo es una variable global a todos los procesos *)int claverepeat

clave=1;repeat swap(clave, cerrojo)until clave=0;Sección críticaswap(clave,cerrojo);Sección restante

until false

?6


11

Sincronización Semáforos (I)

? Las soluciones hardware anteriores no son fáciles de generalizar a problemas más complejos

? Semáforo (S): estructura de datos formada por una variable tipo entero y una cola de procesos en espera

? A un semáforo sólo se puede acceder mediante dos operaciones P y V

typedef semaforo{

int contador;cola: lista de procesos;

}


12

Sincronización Semáforos (II)

? P(S)? Decrementa el contador? Si el resultado es negativo suspende

al proceso en la cola asociada

? V(S)? Incrementa el contador? Si el resultado es positivo o cero

despierta a un proceso que se encuentra en la cola del semáforo

S.contador = S.contador-1;if (contador<0){

Insertar_en_Cola(S.cola, Proceso_en_ejecución);

Suspender(Proceso_en_ejecución);}

S.contador = S.contador+1;if (contador<=0){

Extraer_de_Cola(S.cola, Proceso);Activar(Proceso);

}

?7


13

Sincronización Semáforos (III)

? Si el contador es mayor o igual que cero, indica el número de procesos que pueden invocar la operación P sin suspenderse

? Si el contador es menor o igual que cero, su valor absoluto indica el número de procesos suspendidos en la cola asociada al semáforo

? P y V (suministradas por el SO) deben realizarse de forma atómica ya que su código es una sección crítica

? El uso de semáforos no supone espera activa por lo que no exige gasto innecesario de CPU


14

Sincronización Empleo de Semáforos (I)

? Problema de la sección crítica para n procesos? Se tienen n procesos que comparten datos pero sólo uno de puede acceder a

ellos (Exclusión Mutua, mutex)? Se define el semáforo

? Cada proceso Pi tiene la estructura siguiente

var mutex: semaforo(1) (*El valor inicial del contador es 1*)

.

.P(mutex); /*Sección de entrada */Sección crítica

V(mutex); /* Sección de salida */Sección restante

.

.

?8


15

Sincronización Empleo de Semáforos (II)

? Secuenciación de dos secciones de código de procesos diferentes

? Se pretende ejecutar B en Pj despues de A en Pi? La solución consiste en crear un semáforo S con S.contador = 0 y definir las

secuencias de Pi y Pj como sigue

Pi: Pj:

..... .....A P(S)V(S) B..... .....


16

Sincronización Empleo de Semáforos (III)

? Aparición de interbloqueos? Al utilizar semáforos se pueden dar situaciones en que ningún proceso

pueda acceder a su sección crítica y todos los procesos que comparten el semáforo estén suspendidos

? Supongamos que tenemos dos procesos P1 y P2 que comparten dos semáforos S y Q

P1: P2:

..... .....P(S); P(Q);P(Q); P(S);..... .....V(S); V(Q);V(Q); V(S);..... .....

P2: P(Q)

P1: P(S)

P1: P(Q) (se suspende)

P2: P(S) (se suspende)

?9


17

Sincronización Construcciones Lingüísticas

? La utilización incorrecta de los semáforos pueden provocar errores de sincronización

? Para evitar estos errores se han diseñado construcciones lingüísticas de alto nivel que simplifican la programación de aplicaciones concurrentes.

? Construcciones teóricas

? Monitores: estructuras de alto nivel que facilitan la utilización de esquemas de sincronización

? Regiones críticas

? Construcciones prácticas

? Tipos protegidos en ADA’95? Objetos de sincronización en JAVA

?1


1


Sincronización de Threads

? Sincronización de threads? Semáforos? Mutex (esperas a corto plazo)? Variables condicionales (esperas a largo plazo)

? Exclusión mutua? Mutex o candado: mecasnismo de sincronización más sencillo y eficiente? Sirve para obtener acceso exclusivo a las variables o recursos? En POSIX.1c son variables de tipo pthread_mutex_t (estructura que

almacena todos los datos concernientes al mutex)


2


Funciones para mutex (I)

? Las funciones básicas para creación y manejo de mutex se muestran en la tabla siguiente

Función Descripción

pthread_mutex_init Inicializa una variable de tipo pthread_mutex_t

pthread_mutex_destroy Destruye una variable mutex

pthread_mutex_lock Protege la sección crítica (operación P)

pthread_mutex_unlock Libera la protección de la sección crítica (op. V)

pthread_mutex_trylock Como pthread_mutex_lock pero sin bloqueo

?2


3


Funciones para mutex (II)

? pthread_mutex_init: inicializa una variable de tipo pthread_mutex_t

? Dos parámetros? Puntero a una variable pthread_mutex_t (mutex)? objeto atributo de mutex? Se inicializa por defecto haciendo el segundo parámetro NULL

#include <pthread.h>int pthread_mutex_init (pthread_mutex_t *mutex,

const pthread_mutexattr_t, *attr);

#include<pthread.h>pthread_attr_t my_lock;if (!pthread_mutex_init(&my_lock, NULL))

perror(“No puedo inicializar my_lock”);


4


Funciones para mutex (III)

? pthread_mutex_destroy: destruye la variable mutex

? El mutex no se destruye hasta que está completamente vacío (no hay threads en espera)

? pthread_mutex_lock: operación P de semáforos? Código de la sección de entrada que protege la sección crítica? Si el candado está cerrado, el thread que la invoca se suspende hasta que el

candado quede libre

#include <pthread.h>int pthread_mutex_destroy (pthread_mutex_t *mutex);

#include <pthread.h>int pthread_mutex_lock (pthread_mutex_t *mutex);

?3


5


Funciones para mutex (IV)

? pthread_mutex_unlock: operación v de semáforos? Libera el candado cuando un proceso termina su sección crítica? Si hay algún proceso suspendido en la cola del candado, despierta al

primero.

? Ejemplo

#include <pthread.h>int pthread_mutex_unlock (pthread_mutex_t *mutex);

#include<pthread.h>pthread_mutex_t my_lock;pthread_mutex_init(&mylock, NULL);

pthread_mutex_lock(&my_lock);/* Sección crítica */pthread_mutex_unlock(&my_lock);


6


Funciones para mutex (V)

? pthread_mutex_trylock: igual que pthread_mutex_lock pero no bloquea al proceso llamante si el candado está ocupado

? Ejemplo: productores - consumidores

#include <pthread.h>int pthread_mutex_trylock (pthread_mutex_t *mutex);


Entrada

Salida

P1

C1

P2

Contador = 4

Buffer

?4


7


Ejemplo Mutex

#include <pthread.h>#define BUFSIZE 8static int buffer[BUFSIZE]static int entrada = 0;static int salida = 0;static pthread_mutex_t candado = PTHREAD_MUTEX_INITIALIZER;

/Obtener el siguiente elemento del buffer y colocarlo en *itemp */void get_item(int *itemp){pthread_mutex_lock(&candado);*itemp = buffer[salida];salida = (salida + 1) % BUFSIZE;pthread_mutex_unlock(&candado);return;

}


8


Ejemplo Mutex (cont.)

/*Colocar un elemento en el buffer */void get_item(int item){pthread_mutex_lock(&candado);buffer[entrada] = item;entrada = (entrada + 1) % BUFSIZE;pthread_mutex_unlock(&candado);return;

}

?1


1

Comunicación Comunicación entre Procesos

? Dos modelos complementarios de comunicación? Memoria compartida: los procesos comparten variables mediante las cuales

comparten la información

• Existe un espacio de memoria común• La responsabilidad de la comunicación recae sobre los programadores• El SO sólo proporciona la memoria compartida

? Paso de mensajes: permite a los procesos intercambiar mensajes

• Los procesos tienen espacios de direcciones distintos• Las operaciones básicas de comunicación las proporciona el SO

– send (destino, mensaje)– receive (origen, mensaje)

• Es necesario definir las características de los enlaces


2

Comunicación Comunicación por paso de mensajes

? Características del enlace? Modo de nombrar origen y destino

• Comunicación directa e indirecta

? Capacidad del enlace• Comunicación síncrona o asíncorna

? Modo de establecer la conexión• Datagrama o circuito virtual

? Cantidad de procesos asociados al canal? Cantidad de canales entre cada par de procesos? Tipo de comunicación por el canal

• Unidireccional o bidireccional

? Talla de los mensajes? ........

?2


3

Comunicación Características del enlace (I)

? Modo de nombrar origen y destino: los procesos deben tener un mecanismo para referirse unos a otros? Comunicación directa: es necesario conocer el PID de los procesos que

entran en la comunicación (send y receive lo requieren)• Se establece un canal único entre cada dos procesos• El canal suele ser bidireccional• Variante: recibir de cualquier otro (receive (ANY, mensaje))• Ejemplo (productor - consumidor)

function productor; function consumidor;var item: elem; var item: elem;

repeat repeat item = producir(); receive(productor,item); send(consumidor, item); consumir(item);until false; until false;

end productor; end consumidor;


4

Comunicación Características del enlace (II)

? Comunicación indirecta: los mensajes se envían a través de entidades lógicas que tienen un identificador único en el sistema (puertos o ports)

• Un puerto es anónimo y posee un identificador único• Hay puertos “bien conocidos” (www (80), ftp (21),...)• Varios procesos pueden enviar/recibir al/del mismo puerto (normalemente sólo uno

recive)• Dos procesos pueden compartir más de un puerto• Alternativa en la posesión del puerto

– Pertenece a un solo proceso: un proceso declara un puerto y es el único que puede recibir del mismo. Es necesario disponer de operaciones de creación y destrucción del puerto

– El puerto pertenece al SO: cualquier proceso lo puede utilizar. Además de de send y receive se necesita una operación adicional que asocia el puerto a un proceso (bind)

– Cuando varios procesos pueden recibir de un puerto se necesita un protocolo de comunicación

?3


5

Comunicación Características del enlace (III)

? Modelo de comunicación CLIENTE - SERVIDOR: es un tipo de comunicación indirecta

• Cada recurso del sistema que se desee compartir tiene asociado un proceso servidor• El servidor recibe las peticiones de uso de los clientes en un puerto, las ejecuta y

devuelve una respuesta• Los clientes son los usuarios del recurso, los cuales envían mensajes al servidor

mediante el puerto adecuado y esperan la respuesta• El cliente y el servidor pueden residir en máquinas distintas (sistema distribuido)

C S WWWwww

Nodo Cliente Nodo Servidor

Petición

RespuestaPort


6

Comunicación Características del enlace (IV)

? Ejemplo: código básico del modelo CLIENTE - SERVIDOR.

? En este modelo se suele utilizar el servicio RPC (Remote Procedure Call) que oculta el envío y recepción de la petición y la respuesta

CLIENTE SERVIDOR

... repeatsend(port, petición); receive(port,petición);receive(myport, respuesta); respuesta=hacer(petición);... ret=remitente(petición);

send(ret,respuesta)until false

?4


7

Comunicación Características del enlace (V)

? Capacidad del enlace: capacidad de almacenamiento de mensajes en el canal (nº de mensajes que pueden permanecer en el puerto sin serleídos)? Capacidad cero? comunicación síncrona

• La comunicación sólo se lleva a cabo cuando emisor y receptor han invocado send y receive respectivamente.

• Los procesos se sincronizan mediante el modelo “Rendez- vous” o cita (el primero que llega se bloquea)

P1 P2

send

recv

Susp.

P1 P2

send

recvSusp.


8

Comunicación Características del enlace (VI)

? Capacidad n>0 ? comunicación asíncrona (n finito o n infinito)• Una operación receive de un canal vacío suspende al proceso invocante• Una operación send de un canal lleno puede:

– Suspender al proceso invocante– Perder el mensaje– Devolver un mensaje de error

• Para notificar la lectura de de un mensaje y así simular un sistema síncrono se susan mensajes de reconocimiento ACK

P Q

send (Q, mensaje) receive(P,mensaje)receive(Q,ACK) send(P,ACK)

?5


9

Comunicación Características del enlace (VII)

• En enlaces de capacidad limitada, cuando los productores son muy rápidos es posible desbordar la capacidad del enlace y es necesario utilizar un protocolo de control de flujo para reducir la velocidad de los productores

• En comunicaciones asíncronas no se garantiza el orden correcto de los mensajes recibidos y es necesario adoptar un protocolo (timestamps) para asegurar el orden

? Modo de establecer la conexión? Sin conexión (como el correo): uso de datagramas? Con conexión (como el teléfono): uso de circuitos virtuales

? Cantidad de procesos asociados al canal: dos o más? Cantidad de canales entre cada par de procesos: p. e. instrucciones y

datos? Tipo de comunicación por el canal: unidireccional o bidireccional? Talla de los mensajes: fija o variable

Sistemas Informáticos en Tiempo Real Tema VIII

Tema IV Señales POSIX

1

1. ¿Qué es una señal?

Una señal es una notificación por software a un proceso/thread de la ocurrencia de un evento.

Existe cierto paralelismo con el uso de interrupciones, aunque se trata de

mecanismos totalmente diferentes. En el caso de una interrupción, se implementa mediante el propio hardware del computador de forma que, se interrumpe la instrucción actualmente en curso, para comenzar a ejecutar una nueva.

En el caso de una señal, la aparición del evento es controlada por el

software del S.O. decidiendo cuando se interrumpe el proceso o thread que tiene actualmente los recursos, para activar la tarea asociada a la señal. De igual forma, permite asociar señales independientes a cada proceso o thread en ejecución.

Es conveniente distinguir los diferentes estados en los que se puede encontrar una señal: a. Una señal está asociada a un evento, por lo que cuando dicho evento se produce se dice que la señal se ha generado. b. Se dice que la señal está depositada cuando el proceso asociado emprende una acción en base a ella. c. El tiempo de vida de una señal es el intervalo entre la generación y el depósito de ésta. d. Se dice que una señal está pendiente si ha sido generada pero todavía no está depositada. e. Un proceso atrapa una señal si éste ejecuta el manejador de señal cuando se deposita.

f. Una señal puede ser ignorada por el proceso, es decir que no sea ejecutado ningún manejador al ser depositada. Destacar que aunque no se ejecute ningún manejador la señal si que llega al proceso y éste puede determinar alguna acción en función de ello. El que una señal sea atrapada o ignorada es especificado en la configuración de la señal.

g. La acción que se emprende cuando se genera una señal depende de la máscara de la señal. La máscara contiene una lista de señales que en un determinado momento están bloqueadas. Si se genera una señal y está bloqueada no se pierde, queda pendiente de ser depositada hasta que sea desbloqueada.



2

2. El identificador de una señal.

El identificador de una señal es un número entero, de modo que las

señales tienen asociado un nombre simbólico que comienza con el prefijo SIG. Los nombres de las señales están definidos en el archivo <sys/signal.h>. A continuación se muestra un listado de las señales predefinidas:

Símbolo Significado SIGHUP Hangup SIGKILL Elimina el proceso

……………………… ……………………………………………………… ……………………… ………………………………………………………

SIGALRM Alarm clock SIGTERM software termination signal from kill SIGUSR1 User defined signal 1 SIGUSR2 User defined signal 2

SIGRTMIN first (highest-priority) realtime signal SIGRTMAX last (lowest-priority) realtime signal

3. ¿Cómo se genera una señal?

Las señales son un mecanismo software, por lo que es el propio sistema operativo el que se encarga de su generación en función del evento asociado. Estos eventos pueden tener un origen externo, como la activación de un pin de la CPU o de un determinado registro o puerto del computador. También pueden estar asociados a interrupciones hardware del propio computador, como por ejemplo cuando el contador de un reloj alcanza cierto valor.



3

3.1. Generación una señal desde otro proceso.

Para generar una señal estándar en un proceso determinado desde otro proceso podemos utilizar la función kill(). El primer parámetro pid identifica al proceso que recibirá la señal. En segundo parámetro sig identifica la señal a mandar. La función sigsend() actúa de forma similar. Las sintaxis son:

Las señales de tiempo real, aparte del hecho de ser generadas y depositadas, permiten adicionalmente enviar un valor (entero) al proceso destinatario y al manejador la función sigqueue() permite generar una señal especificando un valor entero y, además, que la señal sea encolada (que se quede en espera con una prioridad) si no puede ser atendida por el proceso

4. ¿Quién recibe una señal? Las señales van dirigidas a procesos, pero dentro de ellos pueden existir varios threads, o sea, pueden ir dirigidas a un thread concreto o a todos dependiendo del tipo de señal. Básicamente existen dos tipos de señales:

• Señales síncronas: Son aquellas que son generadas por la ejecución del código, y por tanto son

generadas por un thread concreto. En este caso la señal puede ser depositada únicamente por el thread que generó el evento.

• Señales asíncronas:

El resto de señales producidas por llamas explícitas (kill()) o por eventos no asociados al código en ejecución. En este caso la señal va dirigida a todos los threads del proceso.

Pero una señal solo puede ser depositada por un thread así que surge la pregunta de ¿cuál será el thread que deposite la señal?. Pues bien, la recibirá uno cualquiera que cumpla una de las siguientes condiciones:

#include <sys/types.h> #include <signal.h>

int kill(pid_t pid, int sig); int sigsend(idtype_t idtype, id_t id, int sig);

int sigqueue(pid_t pid, int signo, const union sigval value); union sigval {

int sival_int; /* integer value */ void *sival_ptr; /* pointer value */

};



4

• El thread está bloqueado esperando la señal. Si existen varios habrá una cola de prioridades.

• El thread no incluye en su máscara de bloqueo la señal en cuestión (la

señal no está bloqueada por el thread).

5. Configuración de una señal.

Debemos tener en cuenta que van a existir dos aspectos diferentes de configuración y gestión de señales ya que las señales asíncronas dependen de la configuración de cada uno de los threads:

• Aquellos aspectos que afectan únicamente al thread que las llama: irán ubicadas generalmente en cada uno de los manejadores del thread.

• Aquellos aspectos comunes a todos los threads: se ubican generalmente

en el thread principal.

La configuración de una señal tiene dos partes fundamentales:

• Decidir entre atrapar la señal (asignar un manejador para la señal (función que se ejecuta cuando es depositada), o bien ignorar la señal. Se trata de un aspecto común para todos los threads.

• Establecer el bloqueo de la señal (la señal queda pendiente de ser

depositada). Es un aspecto de configuración independiente para cada thread.

5.1. Bloqueo de una señal.

El bloqueo de una señal supone que dicha señal quede pendiente de depósito en el caso de que sea generada, es decir, la señal no se pierde sino que su atención es postergada. El bloqueo de una señal por parte de un proceso es específico de cada thread del proceso. Dentro de un proceso pueden existir threads que hayan bloqueado la señal y threads que no la hayan bloqueado, de modo que estos últimos son los únicos que pueden depositar la señal.

La gestión del bloqueo de señales se realiza mediante lo que se

denomina máscara de señal. Esta máscara se maneja mediante una estructura de tipo sigset_t almacenada por el Sistema Operativo para cada thread. La máscara de señal indica la configuración de cada señal (bloqueada o no bloqueada). Adicionalmente, podemos definir nuevos conjuntos de señales de tipo sigset_t que nos permitirán activar o desactivar grupos de señales en cada momento.



5

Las funciones de manejo básico son las siguientes:

• sigemptyset():

Inicializa un conjunto excluyendo todas las señales. Su sintaxis es:

• sigfillset():

Inicializa un conjunto incluyendo todas las señales. La sintaxis es la siguiente:

• sigaddset():

Incluye la señal indicada en el conjunto. La sintaxis es:

• sigdelset():

Excluye la señal indicada en el conjunto. Esta función tiene la siguiente sintaxis:

Disponemos de dos funciones para el bloqueo o desbloqueo de una señal:

• sigprocmask():

Realiza el bloqueo de la señal especificada para un proceso.

• pthread_sigmask()

La función pthread_sigmask() bloquea únicamente al thread que la llama. Destacar que si un thread crea a otro, éste último hereda el bloqueo de las señales.

#include <signal.h>

int sigemptyset(sigset_t *set);

#include <signal.h>

int sigfillset(sigset_t *set);

#include <signal.h> int sigaddset(sigset_t *set, int signo);

#include <signal.h> int sigdelset(sigset_t *set, int signo);



6

Los parámetros de las dos funciones son los mismos:

• how: indica la acción a realizar: SIG_BLOCK, (para bloquear un conjunto de señales), SIG_UNBLOCK para desbloquearlas, SIG_SETMASK copia el conjunto dato en set en la máscara.

• set: es un puntero al conjunto de señales que queremos bloquear o desbloquear (tal como se describió anteriormente).

• oset: si no es NULL almacena el valor de la máscara anterior a la operación.

A continuación se muestra un ejemplo de bloqueo y desbloqueo de una

señal:

5.2. Asignación de un manejador de señal.

El manejador es ni más ni menos que una función que es ejecutada justo cuando se deposita una señal (si no la señal es ignorada y el manejador se inhibe). Para asignar un manejador a una señal concreta se utiliza la función sigaction() que nos permite tres formas de tratar a la señal:

• Ignorar la señal: No se ejecutaría ningún manejador (a pesar de ello la señal si que llegaría al proceso que podría ejecutar una acción).

• Asignar un manejador por defecto.

• Asignar nuestro propio manejador.

Para evitar que se deposite una señal mientras se está configurando se

debe, en primer lugar, bloquear la señal en todo el proceso antes de llamar a la función sigaction(), es decir, para poder configurar una señal ésta debe estar bloqueada.

A continuación, se mostrará un ejemplo de uso de la función sigaction()

donde se podrán analizar cada uno de los parámetros asociados a dicha función.

#include <signal.h> main() { sigset_t sigset; // conjunto de señales // bloquea la señal sigemptyset(&sigset); // crea una máscara vacía sigaddset(&sigset, SIGUSR1); // añade la señal sigprocmask (SIG_BLOCK, &sigset, NULL); // bloque a la señal

// desboquea la señal sigemptyset(&sigset); sigaddset(&sigset, SIGUSR1); sigprocmask(SIG_UNBLOCK, &sigset, NULL); //desbloqu ea la señal }



7

El primer parámetro sig especifica la señal que vamos a configurar. El segundo parámetro act es un puntero a una estructura donde debemos especificar la configuración deseada. Existen dos tipos configuraciones diferentes para esta estructura especificado por el campo sa_flags:

• Estructura estándar: Tiene tres campos importantes:

sa_handler: Se trata de un puntero a una función (manejador de la señal). La función tienen un único parámetro entero que indica el número de la señal. Existen dos valores especiales para el parámetro:

SIG_DFL: asigna un manejador por defecto.

SIG_IGN: ignora la señal (no se ejecuta ningún

manejador).

sa_mask: Especifica la máscara con las señales adicionales que deben serbloqueadas durante la ejecución del manejador (cuando la señal esdepositada). Normalmente asignaremos una máscara vacía.

sa_flags: Especifica opciones especiales. Normalmente será NULL.

• Estructura extendida: Esta especificada en POSIX1.b y permite

proporcionar información adicional (precisa activar el flag SA_SIGINFO). Tiene tres campos importantes:

sa_sigaction: Se trata de un puntero a una función (manejador de la señal). La función tienen tres parámetros:

int sigaction(int sig, const struct sigaction *act, struct sigaction *oact);

struct sigaction {

int sa_flags; union {

void (*_handler)(int); void (*_sigaction)(int, siginfo_t *, void *);

} _funcptr; sigset_t sa_mask; int sa_resv[2];

}; #define sa_handler _funcptr._handler #define sa_sigaction _funcptr._sigaction



8

int: Identificador de la señal.

sig_info_t *: Puntero a una estructura que incluye

información adicional sobre la señal. Dispone, al menos, de los siguientes campos:

� int si_signo: número de señal. � int si_code: causa de la señal.

� union sigval si_value: valor que se

le pasa al manejador de la señal (por ejemplo desde un temporizador, o utilizando la función sigqueue()).

void *: puntero genérico (Actualmente no está definido su uso).

sa_mask : especifica la máscara con las señales adicionales que deben ser bloqueadas durante la ejecución del manejador (cuando la señal es depositada). Normalmente asignaremos una máscara vacía.

sa_flags : debe activar al menos el flag SA_SIGINFO indicando el uso de información adicional.

Veamos un ejemplo de configuración de una señal :

#include <signal.h> main() { struct sigaction act; // manejador señal sigset_t sigset; // conjunto de señales // Primero bloquea la señal sigemptyset(&sigset); // crea una máscara vacía sigaddset(&sigset, SIGUSR1); // añade la señal pthread_sigmask (SIG_BLOCK, &sigset, NULL); // bl oqueo // Configura la señal act.sa_sigaction = ManejadorSig; // manejador de la señal sigemptyset(&(act.sa_mask)); // máscara vacía act.sa_flags = SA_SIGINFO; // Modo extendido if(sigaction(SIGUSR1, &act, NULL)<0) // configura ción perror("Sigaction fallado");

C// � Continua



9

6. Espera de señales.

Existen dos formas de responder ante un evento asíncrono:

• Código usando el manejador. Una forma de ejecutar una tarea ante la ocurrencia de un evento

asíncrono, es configurar una señal con un manejador que incluya el código de la tarea a ejecutar (éste se ejecutará cuando la señal sea depositada). El manejador precisa comportarse correctamente cuando se activa de nuevo la señal antes de terminar la ejecución de la función (esto es, el código de un manejador de señal debe ser reentrante). Como norma general, los manejadores de señal deben ser rutinas muy cortas.

• Código usando el thread.

Dicho thread debe estar dormido (bloqueado) esperando la activación de la señal, poniéndose a ejecutar dicho código cuando la señal sea depositada. Este thread será el único que tendrá desbloqueada la señal con lo que garantizamos que, cuando se genere la señal, será capturada siempre por él. El manejador de la señal (si no es ignorado) seguiría ejecutándose también, por lo que pondremos uno vacío o el valor por defecto SIG_DFL.

// � Continuación

// desboquea la señal sigemptyset(&sigset); sigaddset(&sigset, SIGUSR1); pthread_sigmask (SIG_UNBLOCK, &sigset, NULL); //des bloqueo

while(1) {

// espera indefinidamente la aparición de la señal }

} /* Manejador de la Señal */ void ManejadorSig( int signo, siginfo_t *info, void *context) {

printf("Soy el manejador de la señal # %d Valor: %d ", info->si_signo, info->si_value.sival_int); printf("Code: (%d) ",info->si_code); if( info->si_code == SI_USER) printf("SI_USER \n" ); else if( info->si_code == SI_TIMER ) printf("SI_TIMER \n" ); else if( info->si_code == SI_QUEUE ) printf("SI_QUEUE \n" ); else if( info->si_code == SI_ASYNCIO ) printf("SI_ASYNCIO \n" ); else if( info->si_code == SI_MESGQ ) printf("SI_MESGQ \n" );

}



10

A continuación se enumerarán las posibles funciones de espera de señales:

Señales estándar:

Señales de Tiempo Real:

6.1. Señales estándar. 6.1.1. Espera de señales mediante sigsuspend().

Esta función no especifica la señal depositada sino que su un único parámetro que es un conjunto de señales de tipo sigset_t (máscara) en la que debemos indicar aquellas señales que pueden desbloquearlo.

La función devuelve el control si existe alguna señal dentro del conjunto

que esté pendiente de ser depositada, sino queda bloqueada. Es decir, la función queda bloqueada hasta que una señal del conjunto esté pendiente. La función realiza tres tareas de forma atómica:

• Copia el conjunto pasado como parámetro en la máscara de bloqueo del proceso o thread. De este modo, las señales indicadas en el conjunto pasado como parámetro serán desbloqueadas, y cualquier otra señal que no esté en el conjunto será bloqueada.

• Queda a al espera de que se deposite alguna señal que no esté

bloqueada.

• Cuando es depositada la señal, se reestablecen los bloqueos anteriores.

6.1.2. Espera de señales mediante sigwait(). Esta función se caracteriza principalmente porque proporciona

información de la señal depositada. Se pueden encontrar dos prototipos según

int sigsuspend(const sigset_t *set); //Para procesos int sigwait(sigset_t *set); // Multithread int sigwait(const sigset_t *set, int *sig);

(-D_POSIX_PTHREAD_SEMANTICS)

int sigwaitinfo(const sigset_t *set, siginfo_t *info); int sigtimedwait(const sigset_t *set, siginfo_t *info,




11

la librería utilizada. La función queda bloqueada hasta que una señal del conjunto esté

pendiente, devolviendo como resultado la señal depositada. Como en el caso anterior realiza tres operaciones de forma atómica:

• Copia el conjunto pasado como parámetro en la máscara de bloqueo del proceso o thread. De este modo, las señales indicadas en el conjunto pasado como parámetro serán bloqueadas, y cualquier otra señal que no esté en el conjunto será desbloqueada.

• Queda a al espera de que se deposite alguna señal que no esté

bloqueada.

• Cuando es depositada la señal, se reestablecen los bloqueos anteriores y se devuelve la señal depositada.

6.2. Señales de Tiempo Real. 6.2.1. Espera de señales mediante sigwaitinfo().

Esta función permite la espera de señales de tiempo real que pueden encolarse de forma ordenada por prioridades. Se utiliza con señales en el ango [SIGRTMIN-SIG_RTMAX]. Cuanto menor es el valor de la señal mayor es la prioridad y antes será depositada Incorpora, asimismo, la posibilidad de utilizar información adicional a través de la estructura sig_info. En ella se incluye el número de la señal, la causa de la señal, el valor enviado, etc.

El proceso de bloqueo de la señal y espera es similar a las funciones vistas anteriormente, con la única salvedad de que la función sigtimedwait() permite especificar un intervalo máximo de bloqueo mediante el parámetro timeout de tipo timespec.

¿qué ocurre si la señal sedeposita antes de que se ejecute la llamada a

sigsuspend() o sigwait()?. En este caso se ejecutaría el manejador pero la señal pasaría inadvertida para el thread, que al ejecutar la función de espera de la señal quedaría bloqueada. Se perdería de este modo uno o varios eventos. Para resolverlo debemos mantener bloqueadas todas las señales en todo el proceso desde el comienzo de su ejecución.

De este modo nos aseguramos que no se deposite ninguna señal antes

de que llamemos a sigwait(). La propia llamada a sigwait() va a desbloquear de forma atómica las señales indicadas en el conjunto pasado como parámetro, con lo que aseguramos que no perderemos ningún evento.

A continuación se presenta un ejemplo completo de manejo de señales

para la ejecución asíncrona de tareas.



12

#define _REENTRANT #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <unistd.h> #include <sched.h> #include <pthread.h> #include <signal.h> #include <time.h> #include <sys/time.h> #define SIGNUM SIGRTMAX #define ESPERA_DEF 20000L // 20s void ManejadorSig( int signo, siginfo_t *info, void *context); void * ThreadSig(void *arg); void TestArg(int argc, char *argv[], long *esp); void wait_t(long ms); /******************************* función main *******************************/ int main(int argc, char *argv[]) {

sigset_t sigset; // conjunto de señales pthread_t th_id; // identificador para el thread pthread_attr_t attr; // atributos de los threads int sig = SIGNUM; int ires; long esp;

// comprueba los parámetros

TestArg(argc, argv, &esp); // bloquea la señal // los threads creados heredan la máscara

sigemptyset(&sigset); sigaddset(&sigset, sig); pthread_sigmask(SIG_BLOCK, &sigset, NULL);

//inicializa los parámetros de los threads por defe cto

pthread_attr_init (&attr); // crea el thread de gestión de la señal (hereda la máscara)

ires=pthread_create (&th_id, &attr, ThreadSig, (voi d *)sig); wait_t(esp); // espera un rato

// termina el thread de señal

if (pthread_cancel(th_id)!=0) perror("Cancelando thread"); else printf("Thread de señal, # %d, ha terminado\n",th_i d); wait_t(esp); // espera un rato printf("Main thread, # %d termina\n", pthread_self( ));

} // � Continua



13

/ � Continuación /************************************************** *********** Thread de gestión de la señal *************************************************** **********/ void * ThreadSig(void *arg) {

int sig; struct sigaction act; // manejador señal sigset_t sigset; // conjunto de señales int res; sig = (int)arg; act.sa_sigaction = ManejadorSig; // manejador sigemptyset(&(act.sa_mask)); // sin bloqueos adici onales act.sa_flags = SA_SIGINFO; // información extendi da if(sigaction(SIGNUM, &act, NULL)<0) {

perror("Sigaction fallado"); pthread_exit(NULL);

} printf(" Señal %d atrapada por el proceso: %d threa d: %d\n",

sig, getpid(), pth read_self()); // permite la cancelación del thread

pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL ); pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL) ;

// define el conjunto para la espera // Lee los bloqueos actuales

pthread_sigmask(SIG_SETMASK, NULL, &sigset); sigdelset(&sigset, sig); // desactiva la señal

// Espera la señal o la cancelación del thread

while(1) { // sigwait es un punto de cancelación res= sigwait(&sigset, &sig); if (res!=-1) printf(" Señal %d depositada en el thread: %d\n", s ig,

pthread_self()); }

} // � Continua



14

// � Continuación /************************************************** *********** Manejador de la Señal signo *************************************************** **********/ void ManejadorSig( int signo, siginfo_t *info, void *context) {


} /************************************************** *********** Comprueba los parámetros y asigna su valor *************************************************** **********/ void TestArg(int argc, char *argv[], long *esp) {

if(argc > 2) {

printf("Utilizar %s [espera(ms)]\n", argv[0]); exit(0);

} if(argc==2) *esp = atol(argv[1]); else *esp = ESPERA_DEF; // espera por defecto

} /************************************************** ************ Espera ms_ret milisegundos (no bloquea con threads de usuario) *************************************************** ***********/ void wait_t(long ms_ret) {

timespec_t t1; double t_actual, t_final; clock_gettime(CLOCK_REALTIME, &t1); t_actual= t1.tv_sec + (double) (t1.tv_nsec) /100000 0000L; t_final = t_actual + (double)ms_ret/1000; do {

sched_yield(); /* libera la CPU */ clock_gettime(CLOCK_REALTIME, &t1); t_actual= t1.tv_sec + (double) (t1.tv_nsec) /100000 0000L;

}while (t_actual<t_final); } // Final del Programa

1


1

SITR:Señales POSIX

Índice

ü ¿Qué vamos a estudiar?

• Concepto de Señal POSIX

• Métodos de generación de Señales

• Configuración de Señales POSIX

• Ejecución de tareas ante eventos asíncronos


2

SITR:Señales POSIX

¿Qué es una Señal?

ü Una señal es una notificación por software a un proceso/thread de la ocurrencia de un evento

û Interrupción: notificación por hardware

û Una señal es gestionada por el S.O.

û Se interrumpe la tarea actualmente en curso y se activa la tarea asociada ala señal.

û Permite asociar señales independientes a cada proceso o thread

2


3

SITR:Señales POSIX

Estados de una Señal (1)

ü Estados en los que se puede encontrar una señal:û Generada: Una señal está asociada a un evento, por lo que cuando dicho

evento se produce se dice que la señal se ha generado.û Depositada: Se dice que la señal está depositada cuando el proceso

asociado emprende una acción con base a ella.û Tiempo de vida de una señal es el intervalo entre la generación y el depósito

de ésta.û Pendiente: se dice que una señal está pendiente si ha sido generada pero

todavía no está depositada.û Atrapada: un proceso atrapa una señal si éste ejecuta el manejador de señal

cuando se deposita.

û Ignorada: no es ejecutado ningún manejador al ser depositada. û Bloqueada: Si se genera una señal y está bloqueada no se pierde, queda

pendiente de ser depositada hasta que sea desbloqueda. Se controla mediante la máscara de la señal.


4

SITR:Señales POSIX

Estados de una Señal (2)

Evento

Latencia Activación

El proceso Atrapa la señal

(Se ejecuta el manejador si no está ignorada)

Señal Depositada

El proceso tiene bloqueada la señal

El proceso emprende una acción

Tiempo de Vida Tiempo de ejecución del manejador

Señal Generada

3


5

SITR:Señales POSIX

Identificación de una Señal

ü Número Entero. Etiquetas definidas en <signal.h>

SÍMBOLO SIGNIFICADO

SIGHUP Hangup

SIGKILL Elimina el proceso

……… ………..

SIGALRM Alarm clock

SIGTERM software termination signal from kill

SIGUSR1 User defined signal 1

SIGUSR2 User defined signal 2

SIGRTMIN first (highest-priority) realtime signal

SIGRTMAX last (lowest-priority) realtime signal


6

SITR:Señales POSIX

¿Cómo se genera una Señal?

ü Interrupciones hardware: û Activación de pines (puertos) especiales de la CPU

û Excepciones en la ejecuciónû Relojes

ü Eventos generados por los procesos en ejecución:û Generación desde otro procesoû Generación desde un temporizador

4


7

SITR:Señales POSIX

Generación desde otro proceso

ü Señales estándar:

ü Señales de Tiempo Real:û Permiten enviar información adicionalû Permite que las señales sean encoladas mediante prioridades.

#include <sys/types.h>

#include <signal.h>

int kill(pid_t pid, int sig);int sigsend(idtype_t idtype, id_t id, int sig);

int sigqueue(pid_t pid, int signo, const union sigval value);

union sigval {int sival_int; /* integer value */void *sival_ptr; /* pointer value */

};


8

SITR:Señales POSIX

¿Quién recibe una Señal?

ü Van dirigidas a un proceso, pero pueden existir varios threads dentro del proceso:û Señales síncronas: son aquellas que son generadas por la ejecución del

código, y por tanto son generadas por un thread concreto. En este caso la señal puede ser depositada únicamente por el thread que generó el evento

û Señales asíncronas: el resto de señales producidas por llamas explícitas (kill) o por eventos no asociados al código en ejecución. En este caso la señal va dirigida a todos los threads del proceso.

ü Una señal solo puede ser depositada por un thread así que surge la pregunta de ¿cuál será el thread que deposite la señal?.û La recibirá uno cualquiera que cumpla una de las siguientes condiciones:

• El thread está bloquedado esperando la señal. Si existen varios habrá una cola de prioridades.

• El thread no incluye en su máscara de bloqueo la señal en cuestión

5


9

SITR:Señales POSIX

Configuración de una Señal

ü Para señales asíncronas van a existir dos aspectos diferentes de configuración y gestión de señales:û Aquellos aspectos que afectan únicamente al thread que las llama: irán

ubicadas generalmente en cada uno de los manejadores del thread û Aquellos aspectos comunes a todos los threads: se ubican generalmente en

el thread principal.

ü La configuración de una señal tiene dos partes fundamentales:û Decidir entre atrapar la señal (asignar un manejador para la señal (función

que se ejecuta cuando es depositada), o bien ignorar la señal. Se trata de un aspecto común para todos los threads

û Establecer el bloqueo de la señal (la señal queda pendiente de ser depositada). Es un aspecto de configuración independiente para cada thread


10

SITR:Señales POSIX

Bloqueo de una Señal (1)

ü Supone que dicha señal quede pendiente de depósito en el caso de que sea generada

ü Es específico de cada thread del proceso (se hereda)ü Los threads que no hayan bloqueado la señal son los únicos que pueden

depositar la señal.ü La gestión del bloqueo de señales se realiza mediante lo que se

denomina máscara de señal:û Se maneja mediante una estructura de tipo sigset_t almacenada por el

S.O. para cada thread. û La máscara de señal indica la configuración de cada señal (bloqueada o no

bloqueada).

û Adicionalmente podemos definir nuevos conjuntos de señales de tipo sigset_t que nos permitirán activar o desactivar grupos de señales en cada momento.

6


11

SITR:Señales POSIX


ü Manejo de Conjuntos de Señales (sig_set):

inicializa un conjunto excluyendo todas las señalesint sigemptyset(sigset_t *set);

inicializa un conjunto incluyendo todas las señalesint sigfillset(sigset_t *set);

incluye la señal indicada en el conjunto int sigaddset(sigset_t *set, int signo);

excluye la señal indicada en el conjunto int sigdelset(sigset_t *set, int signo);


12

SITR:Señales POSIX


ü Bloqueo de una señal desde un thread:û Realiza el bloqueo de la señal especificada. û POSIX recomienda utilizar la segunda función ya que garantiza un alcance

del bloqueo limitado al thread que la ejecuta.

û Parámetros:• how: indica la acción a realizar: SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK

• set: es un puntero al conjunto de señales que queremos bloquear o desbloquear

• oset: si no es NULL almacena el valor de la máscara anterior a la operación

int sigprocmask(int how, const sigset_t *set, sigset_t *oset);

int pthread_sigmask(int how, const sigset_t *set, sigset_t *oset);

7


13

SITR:Señales POSIX


ü Ejemplo:

#include <signal.h>

main(){

sigset_t sigset;// conjunto de señales

// bloquea la señalsigemptyset(&sigset);// crea una máscara vacíasigaddset(&sigset, SIGUSR1);// añade la señalsigprocmask (SIG_BLOCK, &sigset, NULL); // bloquea la señal

// desboquea la señalsigemptyset(&sigset);sigaddset(&sigset, SIGUSR1);sigprocmask(SIG_UNBLOCK, &sigset, NULL); //desbloquea la señal

}


14

SITR:Señales POSIX

Asignación de un Manejador (1)

ü El manejador es una función que es ejecutada cuando se deposita una señal (si no es ignorada). Se gestiona mediante la función

sigaction()

ü Permite:û Ignorar la señal: no se ejecutaría ningún manejador (a pesar de ello la señal si

que llegaría al proceso que podría ejecutar una acción)

û Asignar un manejador por defecto

û Asignar nuestro propio manejador

ü Importante: para configurar una señal debe estar bloqueada

8


15

SITR:Señales POSIX


ü Uso de la función sigaction():

int sigaction(int sig, const struct sigaction *act, struct sigaction *oact);

struct sigaction {int sa_flags;union {

void (*_handler)(int);void (*_sigaction)(int, siginfo_t *, void *);

}_funcptr;sigset_t sa_mask;int sa_resv[2];

};#define sa_handler_funcptr._handler#define sa_sigaction_funcptr._sigaction


16

SITR:Señales POSIX


ü Estructura estándar: POSIX1:û sa_handler: se trata de un puntero a una función (manejador de la

señal). La función tienen un único parámetro entero que indica el número de la señal.• SIG_DFL: asigna un manejador por defecto.

• SIG_IGN: ignora la señal (no se ejecuta ningún manejador)

û sa_mask : especifica la máscara con las señales adicionales que deben ser bloqueadas durante la ejecución del manejador (cuando la señal es depositada).

û sa_flags : especifica opciones especiales. Normalmente será NULL

9


17

SITR:Señales POSIX


ü Estructura extendida: POSIX1.b . Proporcionar información adicional (precisa activar el flag SA_SIGINFO):û sa_sigaction: se trata de un puntero a una función (manejador de la

señal). La función tienen tres parámetros:• int : identificador de la señal.• sig_info_t *: puntero a una estructura que incluye información adicional

sobre la señal. Dispone, al menos, de los siguientes campos– int si_signo: número de señal

– int si_code: causa de la señal

– union sigval si_value: valor que se le pasa al manejador de la señal

• void *: puntero genérico (Actualmente no está definido su uso).

û sa_mask : especifica la máscara con las señales adicionales que deben ser bloqueadas

û sa_flags : debe activar al menos el flag SA_SIGINFO indicando el uso de información adicional.


18

SITR:Señales POSIX

Espera de una Señal (1)

ü Ejecución de tareas ante eventos asíncronos:û Código en el manejador de la señal:

• Se ejecuta cuando es depositada• Precisa que el código sea Reentrante.• Funciones pequeñas

û Código en el Thread que recibe la señal:• Uno de los Threads del proceso está esperando que se deposite la señal.

• Al depositarse ejecuta la tarea y vuelve a quedar en espera• El manejador d ela señal seguirá ejecutándose.

û Importante: La señal debe estar bloqueada antes de proceder a su espera para evitar que pueda perderse algún evento.

10


19

SITR:Señales POSIX


ü Funciones: û Señales Estándar:

û Señales de Tiempo Real:

int sigsuspend(const sigset_t *set); //En deshuso

int sigwait(sigset_t *set); // Multithread

int sigwait(const sigset_t *set, int *sig); (-D_POSIX_PTHREAD_SEMANTICS)

int sigwaitinfo(const sigset_t *set, siginfo_t *info);

int sigtimedwait(const sigset_t *set, siginfo_t *info,const struct timespec *timeout);


20

SITR:Señales POSIX


ü Espera de señales estándar sigsuspend() :û No especifica la señal depositada.

û La función queda bloqueada hasta que una señal del conjunto estépendiente.

û Realiza tres operaciones de forma atómica:1. Copia el conjunto pasado como parámetro en la máscara de bloqueo del thread.

(pondremos a cero el bloqueo de la señal que vamos a esperar)

2. Queda a al espera de que se deposite alguna señal que no esté bloqueada

3. Cuando es depositada la señal, se reestablecen los bloqueos anteriores y se devuelve la señal depositada.

11


21

SITR:Señales POSIX


ü Espera de señales estándar sigwait() :û Devuelve la señal que fue depositada.

û Dos prototipos según la librería utilizada. û La función queda bloqueada hasta que una señal del conjunto esté

pendiente, devolviendo como resultado la señal depositada.

û Realiza tres operaciones de forma atómica:1. Desbloquea el conjunto pasado como parámetro en la máscara de bloqueo del

thread. (pondremos a uno la señal que vamos a esperar)


3. Cuando es depositada la señal, se reestablecen los bloqueos anteriores y se devuelve la señal depositada.


22

SITR:Señales POSIX


ü Espera de señales de tiempo real sigwaitinfo() :û permite la espera de señales de tiempo real que pueden encolarse de forma

ordenada por prioridades. û Se utiliza con señales en el rango [SIGRTMIN-SIG_RTMAX]. Cuanto menor

es el valor de la señal mayor es la prioridad y antes será depositadaû Incorpora la posibilidad de utilizar información adicional a través de la

estructura sig_info. En ella se incluye el número de la señal, la causa de la señal, el valor enviado, etc.

û El proceso de bloqueo de la señal y espera es similar a las funciones vistas anteriormente,

û La función sigtimedwait() permite especificar un intervalo máximo de bloqueo mediante el parámetro timeout de tipo timespec

12


23

SITR:Señales POSIX

Resumen de Funciones (1)


Union sigval {int sival_int; void *sival_ptr;

};

<signal.h><sys/types.h>

Especifica el valor devuelto al manejador de la señal

sigset_t Conjunto de señales


void (*_handler)(int);void (*_sigaction)(int,

siginfo_t *, void *);} _funcptr;sigset_t sa_mask;int sa_resv[2];

};#define sa_handler _funcptr._handler#define sa_sigaction _funcptr._sigaction

Estructura de configuración del manejador de la señal

struct timespec {time_t tv_sec;long tv_nsec;};


1

E s c u e l a P o l i t é c n i c a S u p e r i o r d e E l c h e

SISTEMAS INFORMÁTICOS EN TIEMPO REAL

2º Ingeniería Industrial

SEÑALES POSIX

CURSO 00/01

Luis Miguel JiménezLuis Miguel Jiménez

Rafael PuertoRafael Puerto

Departamento de IngenieríaÁrea de Ingeniería de Sistemas y Automática

ISA-UMH © R-00-002v1.0

Sistemas Informáticos de Tiempo Real

2

1133 SEÑALES

Se resumen a continuación los aspectos fundamentales asociados al manejo de señales,centrándose en los mecanismos básicos ofrecidos por la implementación POSIX SUN-Solaris. Estudiaremos las funciones permiten:

• Configurar una señal

• Ejecutar tareas ante eventos asíncronos

13.1 ¿Qué es una Señal?

Una señal es una notificación por software a un proceso/thread de la ocurrencia de unevento.

Existe cierto paralelismo con el uso de interrupciones, aunque se trata de mecanismostotalmente diferentes. En el caso de una interrupción, se implementa mediante el propiohardware del computador de forma que, ante un evento interno o externo (señaladomediante la activación de alguna entrada de la CPU) se interrumpe la instrucciónactualmente en curso, para comenzar a ejecutar una nueva.

En el caso de una señal, la aparición del evento es controlada por el software del S.O.decidiendo cuando se interrumpe el proceso o thread que tiene actualmente los recursos,para activar la tarea asociada a la señal. El soporte software permite que una señal puedaser encolada o enmascarada. De igual forma permite asociar señales independientes acada proceso o thread en ejecución. Se trata por tanto de un mecanismo más flexible ypotente.

Es conveniente distinguir las diferentes estados en los que se puede encontrar una señal:

1. Una señal está asociada a un evento, por lo que cuando dicho evento se producese dice que la señal se ha generado.

2. Se dice que la señal está depositada cuando el proceso asociado emprende unaacción en base a ella.

3. El tiempo de vida de una señal es el intervalo entre la generación y el depósitode ésta.

Capítulo 13: Señales

3

4. Se dice que una señal está pendiente si ha sido generada pero todavía no estádepositada.

5. Un proceso atrapa una señal si éste ejecuta el manejador de señal cuando sedeposita.

6. Una señal puede ser ignorada por el proceso, es decir que no sea ejecutadoningún manejador al ser depositada. Destacar que aunque no se ejecute ningúnmanejador la señal si que llega al proceso y éste puede determinar alguna acciónen función de ello. El que una señal sea atrapada o ignorada es especificado en laconfiguración de la señal.

7. La acción que se emprende cuando se genera una señal depende de la máscarade la señal. La máscara contiene una lista de señales que en un determinadomomento están bloqueadas. Si se genera una señal y está bloqueada no sepierde, queda pendiente de ser depositada hasta que sea desbloqueda.

A lo largo de este capítulo se presentarán dos tipos de señales:

• Señales estándar: son las señales definidas en el estándar POSIX 1. Utilizan lasfunciones originales desarrolladas en UNIX.

• Señales de Tiempo Real: Definidas en POSIX 1.b extienden la funcionalidadpermitiendo el manejo de prioridades, el paso de información a los manejadoresy el encolado de las mismas (permite que varios eventos de la misma señal esténen espera y puedan ser despositados).

Evento

LatenciaActivación

El procesoAtrapa la señal(Se ejecuta el

manejador si noestá ignorada)

SeñalDepositada

El proceso tienebloqueada la

señal

El procesoemprende una

acción

Tiempo de Vida Tiempo deejecución delmanejador

SeñalGenerada


4

13.2 ¿Cómo se identifica una señal?

El identificador de una señal es un número entero, pero para facilitar su utilización todaslas señales tienen asociado un nombre simbólico que comienza con el prefijo SIG. Losnombres de las señales están definidos en el archivo <sys/signal.h> . Realmentebasta con incluir en nuestro programa la cabecera <signal.h> ya que ésta incluye ala anterior. A continuación se muestra un listado de las señales predefinidas:

SÍMBOLO SIGNIFICADOSIGHUP HangupSIGINT Interrupt (rubout)SIGQUIT Quit (ASCII FS)SIGILL illegal instruction (not reset when caught)SIGTRAP trace trap (not reset when caught)SIGIOT IOT instructionSIGABRT used by abort, replace SIGIOT in the futureSIGEMT EMT instructionSIGFPE floating point exceptionSIGKILL kill (cannot be caught or ignored)SIGBUS bus errorSIGSEGV segmentation violationSIGSYS bad argument to system callSIGPIPE Write on a pipe with no one to read itSIGALRM Alarm clockSIGTERM software termination signal from killSIGUSR1 User defined signal 1SIGUSR2 User defined signal 2SIGCLD /SIGCHLD

Child status changeChild status change alias (POSIX)

SIGPWR power-fail restartSIGWINCH window size changeSIGURG urgent socket conditionSIGPOLL /SIGIO

pollable event occurredsocket I/O possible (SIGPOLL alias)

SIGSTOP stop (cannot be caught or ignored)SIGTSTP user stop requested from ttySIGCONT stopped process has been continuedSIGTTIN background tty read attemptedSIGTTOU background tty write attemptedSIGVTALRM virtual timer expiredSIGPROF profiling timer expiredSIGXCPU exceeded cpu limitSIGXFSZ exceeded file size limitSIGWAITING process's lwps are blockedSIGLWP special signal used by thread librarySIGFREEZE special signal used by CPSIGTHAW special signal used by CPRSIGCANCEL thread cancellation signal used by libthreadSIGLOST resource lost (eg, record-lock lost)SIGRTMIN first (highest-priority) realtime signalSIGRTMAX last (lowest-priority) realtime signal

Tabla 13.1 Listado de Señales (Sun-Solaris)


5

Como se puede observar la mayoría de las señales predefinidas están asociados aeventos del propio Sistema Operativo. Su uso está fijado y no puede cambiarse (porejemplo si generamos una señal SIGKILL a un proceso este terminará ya que todoproceso incluye por defecto el manejo de las señales estándar. En la tabla se handestacado en negrita dos grupos de señales:

• Las señales definibles por el usuario SIUSR1, SIGUSR2 pueden ser utilizadaspor los procesos de nuestra aplicación libremente para intercambiar eventos, oasociarlas a temporizadores.

• Las señales SIGRTMIN y SIGRTMAX representan un rango de valores paraseñales asociadas a la gestión de eventos en sistemas de tiempo real, atendidosmediante un mecanismo de prioridades. Se pueden utilizar libremente en lasaplicaciones del usuario.

13.3 ¿Cómo se genera una señal?

Las señales son un mecanismo software, por lo que es el propio sistema operativo el quese encarga de su generación en función del evento asociado. Estos eventos pueden tenerun origen externo, como la activación de un pin de la CPU o de un determinado registroo puerto del computador. También pueden estar asociados a interrupciones hardware delpropio computador, como por ejemplo cuando el contador de un reloj alcanza ciertovalor.

Aparte de este tipo de eventos, una señal puede ser generada por los propios procesosque se están ejecutando en el computador (software). Permite de este modo unmecanismo para que los diferentes procesos se comuniquen entre sí la aparición deeventos que determinan la ejecución del programa.

Vamos a estudiar dos métodos de generación de señales:

13.3.1 Generación una señal desde otro proceso:

Para generar una señal estándar en un proceso determinado desde otro proceso podemosutilizar la función kill()(ver prototipo en la parte inferior). El primer parámetro pididentifica al proceso que recibirá la señal. En segundo parámetro sig identifica la señala mandar. La función sigsend() actúa de forma similar pero permite una gestiónmás potente de los procesos destinatarios de la señal.

#include <sys/types.h>#include <signal.h>

int kill(pid_t pid, int sig);int sigsend(idtype_t idtype, id_t id, int sig);


6

Otra forma sencilla de enviar una señal a un proceso es utilizar el comando kill [-signal] pid desde la consola. Aunque el nombre kill parezca extraño paraenviar una señal, hay que tener en cuenta que muchas señales tiene como accióndetener o terminar un proceso.

Las señales de tiempo real, aparte del hecho de ser generadas y depositadas, permitenadicionalmente enviar un valor (entero) al proceso destinatario y al manejador de laseñal. Las funciones kill() y sigsend() no permiten especificar este valor por loque si se desea enviar tal valor debe usarse la función sigqueue() permite generaruna señal especificando un valor entero. Esta última función incorpora adicionalmentela posibilidad de que la señal sea encolada (que se quede en espera con una prioridad)si no puede ser atendida por el proceso (POSIX1.b).

13.3.2 Generación una señal desde un temporizador:

En un aplicación de tiempo real, el tipo de generación que más nos interesa es laactivación asociada a relojes contadores (temporizadores). El concepto de temporizadorse desarrolla en el siguiente apartado, pero quedémonos con la idea de que se trata de unregistro que se decrementa de forma regular según un reloj. Al alcanzar el valor ceroexpira y genera una señal.

Dentro de la posible configuración del temporizador se puede especificar que al expirarvuelva a al valor original y comience el ciclo de nuevo, permitiendo de este podogenerar señales de forma periódica.

En el capítulo 9 se estudian las funciones asociadas para la generación de señalesmediante temporizadores.

int sigqueue(pid_t pid, int signo, const union sigval value);

union sigval {int sival_int; /* integer value */void *sival_ptr; /* pointer value */

};


7

13.4 ¿Quién recibe una Señal?

Las señales van dirigidas a procesos, pero dentro de ellos pueden existir varios threads.Las señales, por tanto, pueden ir dirigidas a un thread concreto o a todos, esto dependedel tipo de señal. Básicamente existen dos tipos de señales:

1. Señales síncronas: son aquellas que son generadas por la ejecución del código,y por tanto son generadas por un thread concreto. Por ejemplo SIGBUS oSIGFPE son generadas por errores del código ejecutado. En este caso la señalpuede ser depositada únicamente por el thread que generó el evento

2. Señales asíncronas: el resto de señales producidas por llamas explícitas (kill) opor eventos no asociados al código en ejecución. En este caso la señal vadirigida a todos los threads del proceso. Pero una señal solo puede serdepositada por un thread así que surge la pregunta de ¿cuál será el thread quedeposite la señal?. Pues bien, la recibirá uno cualquiera que cumpla una de lassiguientes condiciones:

• El thread está bloquedado esperando la señal. Si existen varios habrá unacola de prioridades.

• El thread no incluye en su máscara de bloqueo la señal en cuestión (laseñal no está bloqueada por el thread)

Generalmente en una aplicación se escogen uno o varios threads para atender aquellasseñales importantes quedando dichos threads bloqueados a la espera de que se genere elevento de forma asíncrona. De este modo aseguramos cual va a ser el thread, que deforma unívoca, va a atender cada señal.

13.5 Configuración de una señal

En primer lugar debemos recordar que las señales asíncronas (que son las queutilizaremos) van dirigidas a todos los threads del proceso y depende de laconfiguración de cada uno de ellos, en cual será depositada. Por ello debemos tener encuenta que van a existir dos aspectos diferentes de configuración y gestión de señales:

q Aquellos aspectos que afectan únicamente al thread que las llama: irán ubicadasgeneralmente en cada uno de los manejadores del thread (función indicada en lacreación de cada thread).

q Aquellos aspectos comunes a todos los threads: se ubican generalmente en elthread principal.

La configuración de una señal tiene dos partes fundamentales:


8

1. Decidir entre atrapar la señal, es decir asignar un manejador para la señal(función que se ejecuta cuando es depositada), o bien ignorar la señal. Se tratade un aspecto común para todos los threads

2. Establecer el bloqueo de la señal (la señal queda pendiente de ser depositada). Esun aspecto de configuración independiente para cada thread

13.5.1 Bloqueo de una señal

El bloqueo de una señal supone que dicha señal quede pendiente de depósito en el casode que sea generada, es decir la señal no se pierde sino que su atención es postergada. Elbloqueo de una señal por parte de un proceso es específico de cada thread del proceso.Por lo tanto, dentro de un proceso pueden existir threads que hayan bloqueado la señal ythreads que no la hayan bloqueado. Estos últimos son los únicos que pueden depositar laseñal (recordemos que una señal solo será depositada por uno de los threads delproceso).

La gestión del bloqueo de señales se realiza mediante lo que se denomina máscara deseñal esta máscara se maneja mediante una estructura de tipo sigset_t almacenadapor el S.O. para cada thread. La máscara de señal indica la configuración de cada señal(bloqueada o no bloqueada). Adicionalmente podemos definir nuevos conjuntos deseñales de tipo sigset_t que nos permitirán activar o desactivar grupos de señales encada momento.

El manejo de estos conjuntos se debe realizar con las funciones suministradas ybásicamente lo que realizan es especificar las señales sobre las que queremos ejecutar laacción correspondiente. Esta acción depende de la función en la que se use dichoconjunto (por ejemplo sigprocmask()). Las funciones de manejo básico son lassiguientes:

sigemptyset(): inicializa un conjunto excluyendo todas las señalessigfillset(): inicializa un conjunto incluyendo todas las señalessigaddset(): incluye la señal indicada en el conjuntosigdelset(): excluye la señal indicada en el conjunto

Una vez especificado el conjunto de señales a través de un conjunto sigset_t,podemos ejecutar su bloqueo o desbloqueo.

Disponemos de dos funciones para el bloqueo o desbloqueo de una señal:sigprocmask() realiza el bloqueo de la señal especificada para un proceso(enalgunas implementaciones afecta a todos los threads, mientras que en otras solo afecta althread que lo ejecutó [SUN-Solaris]). La función pthread_sigmask() bloqueaúnicamente al thread que la llama. Destacar que si un thread crea a otro, éste último

int sigemptyset(sigset_t *set);int sigfillset(sigset_t *set);int sigaddset(sigset_t *set, int signo);int sigdelset(sigset_t *set, int signo);


9

hereda el bloqueo de las señales. En todo caso para programas basados en múltiplesthreads se recomienda el uso de la segunda función.

Los parámetros de las dos funciones son los mismos:• how: indica la acción a realizar: SIG_BLOCK, (para bloquear un conjunto

de señales), SIG_UNBLOCK para desbloquearlas, SIG_SETMASK copia elconjunto dato en set en la máscara.

• set: es un puntero al conjunto de señales que queremos bloquear odesbloquear (tal como se describió anteriormente)

• oset: si no es NULL almacena el valor de la máscara anterior a laoperación

A continuación se muestra un ejemplo de bloqueo y desbloqueo de una señal:

int sigprocmask(int how, const sigset_t *set, sigset_t *oset);

int pthread_sigmask(int how, const sigset_t *set, sigset_t *oset);

#include <signal.h>

main(){

sigset_t sigset; // conjunto de señales

// bloquea la señalsigemptyset(&sigset); // crea una máscara vacíasigaddset(&sigset, SIGUSR1); // añade la señalsigprocmask (SIG_BLOCK, &sigset, NULL); // bloquea la señal

// desboquea la señalsigemptyset(&sigset);sigaddset(&sigset, SIGUSR1);sigprocmask(SIG_UNBLOCK, &sigset, NULL); //desbloquea la señal

}


10

13.5.2 Asignación de un manejador de señal

Para asignar un manejador para una señal concreta se utiliza la funciónsigaction(). Un detalle importante es que, salvo ciertas señales (síncronas),generalmente las señales van dirigidas al proceso aunque este esté formado por variosthreads. De esta forma, la configuración de la señal es común para todos los threads ysolo se realiza una vez.

La función sigaction()nos permite tres pociones:

1. Ignorar la señal: no se ejecutaría ningún manejador (a pesar de ello laseñal si que llegaría al proceso que podría ejecutar una acción)

2. Asignar un manejador por defecto

3. Asignar nuestro propio manejador

Para evitar que se deposite una señal mientras se está configurando se debe, en primerlugar, bloquear la señal en todo el proceso antes de llamar a la función sigaction().Una vez configurada se procederá a desbloquear dicha señal. Una buena norma esconfigura la señal antes de crear los threads, de forma que el bloqueo sea global.

El primer parámetro sig especifica la señal que vamos a configurar (ver apartado 3.2).El segundo parámetro act es un puntero a una estructura donde debemos especificar laconfiguración deseada. Existen dos tipos configuraciones diferentes para esta estructura.El uso de una u otra viene especificado por el campo sa_flags :

• Estructura estándar: es la más antigua y está soportada por todas lasimplementaciones POSIX1. El thread que deposita la señal y el manejador dedicha señal, reciben únicamente el número de la señal que se ha generado. Tienetres campos importantes:q sa_handler: se trata de un puntero a una función (manejador de la

señal). La función tienen un único parámetro entero que indica el número dela señal. Existen dos valores especiales para el parámetro sa_handler:

int sigaction(int sig, const struct sigaction *act,struct sigaction *oact);


void (*_handler)(int);void (*_sigaction)(int, siginfo_t *, void *);

} _funcptr;sigset_t sa_mask;int sa_resv[2];

};#define sa_handler _funcptr._handler#define sa_sigaction _funcptr._sigaction


11

o SIG_DFL: asigna un manejador por defecto.o SIG_IGN: ignora la señal (no se ejecuta ningún manejador)

q sa_mask : especifica la máscara con las señales adicionales que deben serbloqueadas durante la ejecución del manejador (cuando la señal esdepositada). Normalmente asignaremos una máscara vacía.

q sa_flags : especifica opciones especiales. Normalmente será NULL

• Estructura extendida: esta especificada en POSIX1.b y permiteproporcionar, tanto al thread que deposita la señal como al manejador de laseñal, información adicional (precisa activar el flag SA_SIGINFO).Tiene trescampos importantes:q sa_sigaction: se trata de un puntero a una función (manejador de la

señal). La función tienen tres parámetros:o int : identificador de la señal.o sig_info_t *: puntero a una estructura que incluye información

adicional sobre la señal. Dispone, al menos, de los siguientes campos§ int si_signo: número de señal§ int si_code: causa de la señal§ union sigval si_value: valor que se le pasa al

manejador de la señal (por ejemplo desde un temporizador, outilizando la función sigqueue())

o void *: puntero genérico (Actualmente no está definido su uso).

Como en el caso anterior existen dos valores especiales:o SIG_DFL: asigna un manejador por defecto.o SIG_IGN: ignora la señal (no se ejecuta ningún manejador)

q sa_mask : especifica la máscara con las señales adicionales que deben serbloqueadas durante la ejecución del manejador (cuando la señal esdepositada). Normalmente asignaremos una máscara vacía.

q sa_flags : debe activar al menos el flag SA_SIGINFO indicando el usode información adicional.

El parámetro oact devuelve la configuración previa a la ejecución de sigaction().Este parámetro generalmente se pone a NULL, indicando que no devuelva dichainformación.


12

Veamos un ejemplo de configuración de una señal :

#include <signal.h>

main(){

struct sigaction act; // manejador señalsigset_t sigset; // conjunto de señales

// Primero bloquea la señalsigemptyset(&sigset); // crea una máscara vacíasigaddset(&sigset, SIGUSR1); // añade la señalpthread_sigmask (SIG_BLOCK, &sigset, NULL); // bloqueo

// Configura la señalact.sa_sigaction = ManejadorSig; // manejador de la señalsigemptyset(&(act.sa_mask)); // máscara vacíaact.sa_flags = SA_SIGINFO; // Modo extendido

if(sigaction(SIGUSR1, &act, NULL)<0) // configuraciónperror("Sigaction fallado");

// desboquea la señalsigemptyset(&sigset);sigaddset(&sigset, SIGUSR1);pthread_sigmask (SIG_UNBLOCK, &sigset, NULL); //desbloqueo

while(1){

// espera indefinidamente la aparición de la señal}

}

/* Manejador de la Señal */void ManejadorSig( int signo, siginfo_t *info, void *context){

printf("Soy el manejador de la señal # %d Valor: %d ",info->si_signo, info->si_value.sival_int);

printf("Code: (%d) ",info->si_code);if( info->si_code == SI_USER)

printf("SI_USER \n" );else if( info->si_code == SI_TIMER )

printf("SI_TIMER \n" );else if( info->si_code == SI_QUEUE )

printf("SI_QUEUE \n" );else if( info->si_code == SI_ASYNCIO )

printf("SI_ASYNCIO \n" );else if( info->si_code == SI_MESGQ )

printf("SI_MESGQ \n" );}


13

13.6 Espera de señales

Una forma de ejecutar una tarea ante la ocurrencia de un evento asíncrono, es configuraruna señal con un manejador que incluya el código de la tarea a ejecutar. Cuando la señalsea atrapada en un thread (basta que exista uno que no tenga bloqueda dicha señal) seejecutaría el manejador de la señal.

El problema radica en que el código de un manejador de señal debe ser reentrante, esdecir, que se comporte correctamente cuando se activa de nuevo la señal antes determinar la ejecución de la función. Muchas funciones y llamadas al sistemas son noreentrantes por lo que no pueden usarse en un manejador de señal.

Como norma general, los manejadores de señal deben ser rutinas muy cortas por lo quegeneralmente no es el sitio adecuado para ubicar la tarea que queremos ejecutar deforma asíncrona.

La estrategia correcta es situar el código de la tarea en un thread. Dicho thread debeestar dormido (bloqueado) esperando la activación de la señal, poniéndose a ejecutardicho código cuando la señal sea depositada. Este thread será el único que tendrádesbloqueada la señal con lo que garantizamos que, cuando se genere la señal, serácapturada siempre por él. El manejador de la señal (si no es ignorado) seguiríaejecutándose también, por lo que pondremos uno vacío o el valor por defectoSIG_DFL.

Dentro de la especificación POSIX existen varias funciones para bloquear un proceso othread esperando una señal. La más antigua recogida en la especificación POSIX 1 es lafunción sigsuspend(), diseñada para trabajar con procesos, aunque también puedeser utilizada en programas con múltiples threads. Esta función tiene una limitaciónimportante cuando el proceso o thread está esperando por varias señales, y es que noespecifica que señal fue depositada. En a especificación POSIX 1.b se añadió unanueva función sigwait() que es la recomendada para aplicaciones multithreads yque añade la funcionalidad de devolver la señal que fue depositada. Se recomiendautilizar siempre esta última función.

Si se trabaja con señales de tiempo real (pueden ser encoladas con un mecanismo deprioridades), se dispone de las funciones sigwaitinfo() y sigtimedwait().Incorporan un parámetro adicional (info) donde se almacena la información extendidadisponible en este tipo de señales (ver apartado 13.4.2). La última función permite

int sigsuspend(const sigset_t *set); //Para procesos

int sigwait(sigset_t *set); // Multithread

int sigwait(const sigset_t *set, int *sig);(-D_POSIX_PTHREAD_SEMANTICS)

int sigwaitinfo(const sigset_t *set, siginfo_t *info);

int sigtimedwait(const sigset_t *set, siginfo_t *info,const struct timespec *timeout);


14

especificar un tiempo de espera máximo (timeout), si se sobrepasa dicho intervalo detiempo ni no se deposita ninguna señal la función devuelve el control.

13.6.1 Espera de señales mediante sigsuspend()

La función sigsupsend()tiene un único parámetro que es un conjunto de señalesde tipo sigset_t (máscara) en la que debemos indicar aquellas señales que puedendesbloquearlo (un proceso puede estar atendiendo varias señales).

La función devuelve el control si existe alguna señal dentro del conjunto que estépendiente de ser depositada, sino queda bloqueada. El valor devuelto de la función es uncódigo de error.

La función realiza tres tareas de forma atómica:1. Copia el conjunto pasado como parámetro en la máscara de bloqueo del

proceso o thread. De este modo, las señales indicadas en el conjunto pasadocomo parámetro serán desbloqueadas, y cualquier otra señal que no esté en elconjunto será bloqueada.

2. Queda a al espera de que se deposite alguna señal que no esté bloqueada3. Cuando es depositada la señal, se reestablecen los bloqueos anteriores.

Otro aspecto importante de esta función es que no indica cual fue la señal depositada,por lo que será misión del manejador activar alguna variable global que indique althread esta información.

13.6.2 Espera de señales mediante sigwait()

La función sigwait() es más potente, ya que proporciona información de la señaldepositada. Se pueden encontrar dos prototipos según la librería utilizada. El primeromás habitual tiene un parámetro con el mismo formato y uso de la funciónsigsupsend(). La señal depositada es indicada el parámetro devuelto por la función.El segundo prototipo precisa compilar la aplicación con el modificador -D_POSIX_PTHREAD_SEMANTICS, e incluye un parámetro adicional int *sig,utilizado para devolver la señal que ha sido depositada, siguiendo el nuevo formatoPOSIX (se recomienda que los valores devueltos por una función indiquen solo elestado de error, utilizando parámetros para devolver cualquier otra información). Entodo caso, la funcionalidad es la misma.

La función queda bloqueada hasta que una señal del conjunto esté pendiente,devolviendo como resultado la señal depositada. Como en el caso anterior realiza tresoperaciones de forma atómica:

1. Copia el conjunto pasado como parámetro en la máscara de bloqueo delproceso o thread. De este modo, las señales indicadas en el conjunto pasadocomo parámetro serán bloqueadas, y cualquier otra señal que no esté en elconjunto será desbloqueada.



15

3. Cuando es depositada la señal, se reestablecen los bloqueos anteriores y sedevuelve la señal depositada.

13.6.3 Espera de señales de tiempo real: sigwaitinfo(), sigtimedwait()

La función sigwaitinfo() permite la espera de señales de tiempo real que puedenencolarse de forma ordenada por prioridades. Se utiliza con señales en el rango[SIGRTMIN-SIG_RTMAX]. Cuanto menor es el valor de la señal mayor es laprioridad y antes será depositada

Incorpora, asimismo, la posibilidad de utilizar información adicional a través de laestructura sig_info. En ella se incluye el número de la señal, la causa de la señal, elvalor enviado, etc.

El proceso de bloqueo de la señal y espera es similar a las funciones vistasanteriormente, con la única salvedad de que la función sigtimedwait() permiteespecificar un intervalo máximo de bloqueo mediante el parámetro timeout de tipotimespec (ver tema 9). En las aplicaciones de tiempo real es importante evitarbloqueos indefinidos de forma que exista en las tareas un tiempo de respuesta máximo.

Un problema que debemos resolver (con ambas funciones) es ¿qué ocurre si la señal sedeposita antes de que se ejecute la llamada a sigsuspend() o sigwait()?. Eneste caso se ejecutaría el manejador pero la señal pasaría inadvertida para el thread, queal ejecutar la función de espera de la señal quedaría bloqueada. Se perdería de estemodo uno o varios eventos. Para resolverlo debemos mantener bloqueadas todas lasseñales en todo el proceso desde el comienzo de su ejecución. De este modo nosaseguramos que no se deposite ninguna señal antes de que llamemos a sigwait(). Lapropia llamada a sigwait() va a desbloquear de forma atómica las señales indicadas en elconjunto pasado como parámetro, con lo que aseguramos que no perderemos ningúnevento.

Como se indicó anteriormente, una buena norma es bloquear todas las señales que nosinteresen en la configuración inicial (main) antes de crear ningún thread, de este modoaseguramos que los thread creados posteriormente hereden las señales bloqueadas.

A continuación se presenta un ejemplo completo de manejo de señales para la ejecuciónasíncrona de tareas.


16

#define _REENTRANT

#include <stdio.h>#include <stdlib.h>#include <errno.h>#include <unistd.h>#include <sched.h>#include <pthread.h>#include <signal.h>#include <time.h>#include <sys/time.h>

#define SIGNUM SIGRTMAX#define ESPERA_DEF 20000L // 20s

void ManejadorSig( int signo, siginfo_t *info, void *context);void * ThreadSig(void *arg);void TestArg(int argc, char *argv[], long *esp);void wait_t(long ms);

/*******************************función main

*******************************/int main(int argc, char *argv[]){

sigset_t sigset; // conjunto de señalespthread_t th_id; // identificador para el threadpthread_attr_t attr; // atributos de los threadsint sig = SIGNUM;int ires;long esp;

// comprueba los parámetrosTestArg(argc, argv, &esp);

// bloquea la señal// los threads creados heredan la máscarasigemptyset(&sigset);sigaddset(&sigset, sig);pthread_sigmask(SIG_BLOCK, &sigset, NULL);

//inicializa los parámetros de los threads por defectopthread_attr_init (&attr);// crea el thread de gestión de la señal (hereda la máscara)ires=pthread_create (&th_id, &attr, ThreadSig, (void *)sig);

wait_t(esp); // espera un rato

// termina el thread de señalif (pthread_cancel(th_id)!=0)

perror("Cancelando thread");else

printf("Thread de señal, # %d, ha terminado\n",th_id);

wait_t(esp); // espera un ratoprintf("Main thread, # %d termina\n", pthread_self());

}// -à Continua


17

13.7// -à Continuación

/*************************************************************Thread de gestión de la señal*************************************************************/

void * ThreadSig(void *arg){

int sig;struct sigaction act; // manejador señalsigset_t sigset; // conjunto de señalesint res;

sig = (int)arg;

act.sa_sigaction = ManejadorSig; // manejadorsigemptyset(&(act.sa_mask)); // sin bloqueos adicionalesact.sa_flags = SA_SIGINFO; // información extendida

if(sigaction(SIGNUM, &act, NULL)<0){

perror("Sigaction fallado");pthread_exit(NULL);

}

printf(" Señal %d atrapada por el proceso: %d thread: %d\n",sig, getpid(), pthread_self());

// permite la cancelación del threadpthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL);pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);

// define el conjunto para la espera// Lee los bloqueos actualespthread_sigmask(SIG_SETMASK, NULL, &sigset);sigdelset(&sigset, sig); // desactiva la señal

// Espera la señal o la cancelación del threadwhile(1){

// sigwait es un punto de cancelaciónres= sigwait(&sigset, &sig);

if (res!=-1)printf(" Señal %d depositada en el thread: %d\n",

sig, pthread_self());}

}

// -à Continua


18

// -à Continuación

/*************************************************************Manejador de la Señal signo*************************************************************/

void ManejadorSig( int signo, siginfo_t *info, void *context){

printf("Soy el manejador de la señal # %d Valor: %d ",info->si_signo, info->si_value.sival_int);

}

/*************************************************************Comprueba los parámetros y asigna su valor*************************************************************/

void TestArg(int argc, char *argv[], long *esp){

if(argc > 2){ printf("Utilizar %s [espera(ms)]\n", argv[0]);

exit(0); }if(argc==2) *esp = atol(argv[1]);else *esp = ESPERA_DEF; // espera por defecto

}

/**************************************************************Espera ms_ret milisegundos (no bloquea con threads de usuario)**************************************************************/

void wait_t(long ms_ret){

timespec_t t1;double t_actual, t_final;

clock_gettime(CLOCK_REALTIME, &t1);t_actual= t1.tv_sec + (double) (t1.tv_nsec) /1000000000L;t_final = t_actual + (double)ms_ret/1000;

do {sched_yield(); /* libera la CPU */clock_gettime(CLOCK_REALTIME, &t1);t_actual= t1.tv_sec + (double) (t1.tv_nsec) /1000000000L;

}while (t_actual<t_final);}

// Final del Programa


19

13.8 Resumen de funciones POSIX de manejo de señales

A continuación se resumen las estructuras de datos y funciones POSIXestudiadas que permiten el manejo de señales:


Union sigval {int sival_int;void *sival_ptr;

};

Especifica el valordevuelto al manejador dela señal

sigset_t Conjunto de señalesstruct sigaction {int sa_flags;union {

void (*_handler)(int);void (*_sigaction)(int,

siginfo_t *, void *);} _funcptr;sigset_t sa_mask;int sa_resv[2];

};#define sa_handler _funcptr._handler#define sa_sigaction

_funcptr._sigaction

<signal.h>

<sys/types.h>

Estructura deconfiguración delmanejador de la señal

struct timespec {

time_t tv_sec;

long tv_nsec;

};



20

FUNCIÓN CABECERA DESCRIPCIÓN

int kill(pid_t pid, int sig); Envía una señal a un procesoint sigsend(idtype_t idtype,

id_t id, int sig);Envía una señal a un conjuntode procesos

int sigqueue(pid_t pid, int signo,const union sigval value);

<signal.h>

Envía una señal a un procesojunto con un valor almanejador. La señal esencolable

int sigemptyset(sigset_t *set); Configura un conjunto de señalesvacío (todas desactivas)

int sigfillset(sigset_t *set); Configura un conjunto de señalescon todas activadas

int sigaddset(sigset_t *set, intsigno);

Añade una señal a un conjunto(activa)

int sigdelset(sigset_t *set, intsigno);

<signal.h>

Borra una señal de un conjunto(desactiva)

int sigprocmask(int how, constsigset_t *set, sigset_t *oset);

Configura la mascara de bloqueo

int pthread_sigmask(int how, constsigset_t *set, sigset_t *oset);

Configura la mascara de bloqueo

int sigaction(int sig, const structsigaction *act,struct sigaction *oact);

<signal.h>

Configura el manejador de unaseñal

int sigsuspend(const sigset_t *set);Suspende un proceso o threadhasta que sea depositada unaseñal

int sigwait(sigset_t *set);

int sigwait(const sigset_t *set, int*sig);(-D_POSIX_PTHREAD_SEMANTICS)

<signal.h>

Suspende un proceso o threadhasta que sea depositada unaseñal. Devuelve el número de laseñal.

int sigwaitinfo(const sigset_t *set,siginfo_t *info);

Suspende un proceso o threadhasta que sea depositada unaseñal de tiempo real. Devuelveuna estructura con informaciónadicional.

int sigtimedwait(const sigset_t *set,siginfo_t *info, const structtimespec *timeout);

Suspende un proceso o threadhasta que sea depositada unaseñal de tiempo real. Seespecifica un intervalo de esperamáximo. Devuelve una estructuracon información adicional.


21

Resumen del capítulo

Este capítulo se ha dedicado a ofrecer una visión general del manejo de señalesorientado fundamentalmente a al ejecución de tareas ante eventos asíncronos.El siguiente cuadro resume de forma esquematizada el contenido del capítulo

Señales POSIXSeñales POSIX

Conceptos acercade Señales

Conceptos acercade Señales

¿Qué es unaSeñal?

¿Qué es unaSeñal?

¿Cómo seIdentifica

una señal?

¿Cómo seIdentificauna señal?

¿Cómo seGenera

una señal?

¿Cómo seGenera

una señal?

Desde otroprocesoDesde otro

proceso

Desde unTemporizadorDesde un

Temporizador

Configuraciónde una Señal

Configuraciónde una Señal

Bloqueo deuna señal

Bloqueo deuna señal

Asignar unmanejadorAsignar un

manejador

Espera deSeñales

Espera deSeñales

EjemploEjemplo


22

Bibliografía del capítulo

“Real-Time Systems and Programming Languages”(2ª edición)A. Burns, A. Wellings, Addison-Wesley 1997

“Sistemas Operativos. Conceptos Fundamentales” (3ª ed.)A. Silberschatz, J. Peterson, P. Galvin, Ed. Addison-Wesley, 1992

“UNIX Programación Práctica”K.A. Robbins, S. Robbins, Prentice-Hall 1997

“Multithreading Programming with Pthreads”B. Lewis, D.J. Berg, Prentice-Hall Sun Microsystems, 1998

“Programming for the Real World. POSIX.4”B. O. Gallmeister, Ed. O’Reilly & Associates 1995

•1


1

SITR: RedesIntroducción

Objetivos

ü Describir y analizar los elementos que conforman un sistema distribuido, justificando su importancia en aplicaciones industriales

ü ¿Qué vamos a estudiar?û Introducción a los sistemas distribuidos. Modelo OSIû Estudio de la familia de protocolos de comunicación TCP/IP.

• Direccionamiento MAC/IP. Protocolos ARP, RARP

• Protocolo de señalización ICMP

• Protocolo de red IP.

• Protocolos de transporte TCP/UDP.

û Comunicación entre procesos distribuidos. • Estudio del modelo de sockets.

• Llamadas a procedimientos remotos.Protocolo RPC.

&& El estudio de los aspectos de señalización y protocolos de bajo nivel se desarrollarán en la asignatura Sistemas Informáticos Industriales


2


Bibliografía

ü "Redes de Computadoras", A. Tannenbaum, Prentice-Hall

ü "TCP/IP Illustrated Vol.1", W. Stevens, Addison-Wesley

ü “Introducción a TCP/IP”, L.M Crespo, Universidad de Alicante

ü "UNIX Programación Práctica", Robbins, Prentice-Hall

ü “TCP/IP en UNIX”, J.M. Alonso, RA-MA

•2


3


Índice

ü Conceptos Previos

ü Resumen Histórico

ü Tipos de Redes: alcance, topología, ...

ü Arquitectura de Red

ü Modelo ISO/OSI

ü Modelo TCP/IP


4


Conceptos Previos

ü DEFINICIÓN: Red de Computadoresû "Conjunto de recursos informáticos interconectados. Un recurso

informático incluye todos aquellos elementos físicos (hardware) o lógicos (programas de aplicación o del sistema) que intervienen en el proceso considerado (comunicación de datos)”

ü Sistema Distribuido Red de Computadoresû Sistema informático, cuyas aplicaciones (procesos) se ejecutan varios nodos

de una red de computadoresû Se centra en las aplicaciones y no en la estructura física de la redû Está soportado por el propio Sistema Operativo

•3


5


Historia Redes de Computadores

ü Inicio en la década 1960û SAGE (1958) U.S. Air Force

û ARPANET (1970) →→ Internetû Redes Privadas: IBM →→ SNA (1974) , DIGITAL →→ DNA (1976)û (1976) X.25 (CCITT) Conmutación de paquetes

X.21 (CCITT) Conmutación de circuitos

û OSI IS/7498 (ISO) 1977 →→ 1984û IEEE 802.X LAN (1982)

û RDSI (1990)û ATM / Frame Realyû Internet 2

ü Normalizaciónû EUROPA: ITU-T (CCITT), ECMAû USA: ANSI, EIA, ISO, IEEE


6


Clasificación: Alcance

LAN WAN

Alcance 10 m AA1 Km > 10 Km

Vel. > 1 Mbit/s 100 Kbits/s

Tipo Sist. Sist. Distribuidos OrdenadoresAutónomos

Control Control por elUsuario/Empresa

Control por el Estado

Medio Cable Privado Red Telefónica

Inf. Digital Analógica/ Digital

Errores 1 en 109

1 en 105

T. Com. Difusión amplia Punto a Punto

Topolog. Bus, Anillo Malla, Estrella

0,1 m

100 Km

1 Km

10 Km

100 m

10 m

1 m

Placas C.I. µµP

WAN (Redes de área amplia)

LAN (Redes de área local)

Sistemas Multiprocesadores

Interconexión de redes WAN

MAN (Campus)

•Area amplia (WAN)

•Area Local(LAN)

•4

Sistemas Informát i cos de Tiempo RealSistemas Informát i cos de Tiempo RealI S A - U M H © T - 9 9 - 0 1 2 V 1 . 0

7

S I T R : R e d e sI n t r o d u c c i ó n

Clasificación:Técnica de Compartición

ü Redes de área amplia:

û Conmutación de circuitos : RTC/RDSI

û Conmutación de paquetes: X25

Conmutación de tramas: Frame-Realy

Conmutación de celdas: ATM

ü Redes de área local:

û Selección: Paso de testigo (Token Bus, Token Ring)

û Contienda: CSMA/CD

û Reserva


8


Red de Com. de Circuitos

MODEM

RED TEL. CONM.

MODEM

•5


9


Red de Com. de Paquetes

PAD

IMP

IMP

IMP

ROUTER

X.25X.25

X.29

X.28

PADX.3

X.28

RED COM. PAQ.


10


Clasificación: Topología

ü Punto a punto

ü Difusión amplia

ÁrbolAnillo

Malla

Estrella

Bus Satélite Anillo

•6


11


Interconexión de Redes

ü GATEWAY (Pasarela): une dos redes diferentes (no OSI)

ü REPEATER (Repetidor): une dos redes iguales (amplifica la señal)

ü BRIDGE (Puente): une redes con diferente nivel de enlace (dos redes de área localdiferentes)

ü ROUTER (Encaminador): une dos redes con diferente nivel de red ( red de área local <=> Red X.25)

PAD

IMP ROUTERX.25

X.28

RED COM. PAQ.

BRIDGE

ETHERNET TOKEN-BUS

RED SNA (IBM)

IMP

REPEATER

GATEWAY

ETHERNET


12


Arquitectura de Red (1)

ü Def: “Conjunto de capas y protocolos perfectamente definidos e implementados”

û El diseño está basado en capas: dividir el problema global de lacomunicación en varios subproblemas

û Cada nivel o capa proporciona servicios al nivel superior ocultando los detalles de implementación (Abstracción)

•Interfase: comunicación

entre niveles

•Protocolo: comunicación

entre dos entidades del mismo nivel

Capa 1

Capa 2

Capa 1

Capa 2

Protocolo

Interfase

Medio

•7


13


Arquitectura de Red (2)

ü Propiedades de cada capa:

û Todos las capas tienen asociados mecanismos de conexión y desconexión

û Pueden tener tipos de transferencia diferentes:• Simplex: un solo sentido

• Half-duplex: bidireccional no simultánea

• Full-duplex: bidireccional simultánea

û Detección-corrección de errores: se da a varios niveles

û Velocidades de emisión y recepción: pueden ser diferentes

û Segmentación de tramas

û Agrupamiento de tramas

û Ordenación de tramas


14


Arquitectura de Red: OSI

ü OSI (Interconexión de Sistemas Abiertos)

ü Norma ISO 7498, ITU-X200

ü Se trata de una arquitectura básica para la interconexión de sistemas abiertos:

û Estudio de base de las tareas que conforman una comunicación de datos

û “Modelo de referencia” : cómo se debe implementar una arquitectura

ü El concepto “Abierto” se refiere a la capacidad de que sistemas de diferentes fabricantes y de diferente diseño se comuniquen entre sí

•8


15


Estudio de Base

ü El diseño es complejo e intervienen numerosos factores.

û Se tiende a un diseño estructurado y a una mayor normalización.

ü Principios para la selección de capas:

û Capa ⇔⇔ nivel diferente de abstracción

û Cada capa debe efectuar una función bien definida

û Las funciones de una capa deben estar normalizadas internacionalmente

û Los límites entre capas se determinan de forma que se minimice el flujo de información en las interfases

û El número de capas debe ser suficiente para no juntar funciones diferentes

û El número de capas debe ser limitado para simplificar la arquitectura


16


Modelo de Referencia OSI

CA

DATOS

DATOS

CP DATOS

CS DATOS

CT DATOS

CR DATOS

CE DATOS

CF DATOS

Medio

Capa Física

Capa Enlace

Capa Red

Capa Transporte

Capa Sesión

Capa Presentación

Capa Aplicación

Capa Física

Capa Enlace

Capa Red

Capa Transporte

Capa Sesión

Capa Presentación

Capa Aplicación

EQUIPO A EQUIPO BProtocolo

Interfase

Flujo real de Datos

Flujo lógico de Datos

Bits

Tramas

Paquetes

Mensajes

Mensajes

Mensajes

•9


17


Protocolos OSI (1)

ü Conjunto de reglas que regulan la comunicación entre entidades del mismo nivel

ü El protocolo incorpora información de control a los datos a transmitir

ü Cada capa incorpora su propia información de control

ü Los datos, más la información de control, son transmitidos de forma transparente por la capa de nivel inferior.

ü La capa que recibe la información, elimina su información de control y envía los datos a la capa superior


18


Protocolos OSI (2)

ü Modos:

û Desconectados: los fragmentos de información son independientes entre sí (Datagrama)

• En algunos casos se envía un acuse de recibo de la información para tener un control de la pérdida de información.

• No hay recuperación de errores.

û Conectados: los fragmentos se envían en secuencia, estando ligados unos a otros

• Requiere tres fases:

– Establecimiento de la conexión

– Permanencia de la conexión para transmitir datos

– Finalizar la conexión

• Cuando se requiere enviar pocos datos, las numerosas comprobaciones lo hacen ineficiente

• Permite recuperar errores y asegurar la secuenciación

û Conectados con conexión no asegurada: no se realizan comprobaciones. (Voz digitalizada)

•10


19


Capa Física

ü Transmitir/recibir una sucesión de bits (ristra) a través de un canal de comunicación.

ü Define:

û Especificaciones de la conexión mecánica: (n11 contactos, tipo de conector, función de cada contacto)

û Topología

û Especificaciones de la conexión eléctrica/ señal óptica.

û Modulación

û Velocidad de transmisión.

û Transmisión uni ó bidireccional.

û Sincronización a nivel de bits.

û Fragmentación/Agrupación de la información.

û Control de errores.

û Difusión de la información (uno o varios destinos).


20


Capa Enlace

ü Dada un ristra de bits que le proporciona el nivel físico, lo convierte en una línea de comunicación que parezca libre de errores de transmisión al nivel de red.

û Los datos a transmitir que recibe del nivel de red los divide en fragmentos (tramas) añadiéndole información de control.

û Transmite secuencialmente la información. puede tener funciones de numeración de fragmentos para reagrupar la información.

û Maneja reconocimiento de recepción de información.

û Reenvío de tramas perdidas.

û Regula el tráfico de información en cuanto a velocidades de transmisión.

•11


21


Capa Red

ü Controla la operatividad de la red, controlando:

û El número de paquetes que se encaminan de una fuente a un destino (control de flujo y de conexión)

û Selección de la ruta óptima

û Traducir nombre lógicos en direcciones físicas

û Control de congestión en la red

û Agrupación o troceado de datos en unidades (paquetes)

û Reensamblado de paquetes.

ü Resolución de problemas de interconexión entre redes heterogéneas.


22


Capa Transporte

ü La comunicación es ya independiente de la red. Es el nivel que enlaza lo que quiere transmitir el usuario con la información que hay que enviar.

ü Puede dividir la conexión para hacerla más rápida (varias conexiones al nivel de transporte).

ü Puede que una conexión SESIÓN mande poca información y se conecte a varias sesiones.

ü Unidad de datos: mensaje

ü Servicios:

û Proporcionar un canal de comunicación extremo a extremo libre de errores (simula un punto a punto)

û Mensajes aislados sin garantías de secuencias

û Destinos múltiples.

û Información del proceso al que corresponde (sistemas multitarea)

û Control de flujo

•12


23


Modelo de Referencia OSI

Medio

Capa Física

Capa Enlace

Capa Red

Capa Transporte

Capa Sesión

Capa Presentación

Capa Aplicación

Capa Física

Capa Enlace

Capa Red

Capa Transporte

Capa Sesión

Capa Presentación

Capa Aplicación

EQUIPO A EQUIPO BProtocolo

Interfase

Flujo real de Datos

Flujo lógico de Datos

Capa Física

Capa Enlace

Capa Red

Capa Física

Capa Enlace

Capa Red

Extremo a Extremo

Punto a Punto

Router Router


24


Capa Sesión

ü Permite el establecimiento de sesiones de comunicación de usuarios entre diferentes computadores, normalmente en "modo conectado" (una vez que se establece la conexión no se interrumpe)

ü SESIÓN: conjunto de acciones de comunicación para establecer un proceso unitario ( Ejem. transmitir un fichero)

û Control de comunicaciones uni ó bidireccional.

û Administración del testigo, evitando que ambos lados traten de realizar la misma operación simultáneamente.

û Establecimiento de puntos de chequeo en la información. En caso de error sólo es necesario retransmitir de nuevo desde el último chequeo

ü Se trata de una capa que no aparece en muchos sistemas

•13


25


Capa Presentación

ü Resuelve el problema de semántica y sintaxis de la información transmitida.

ü Resuelve la codificación de los datos:

û Texto: ASCII, EBCDIC

û Palabras: codificación de bits.

û Números: complemento a 2, coma flotante,...

û Métodos:• Un estación es el maestro y la otra el esclavo: el protocolo convierte los datos a

los de la estación maestra.

• Utilizar una codificación estándar para ambas estaciones.

ü Compresión / descompresión de los datos.

ü Seguridad: criptografía de la información (cifrado / descifrado)


26


Capa Aplicación

ü Conjunto de protocolos que interactúan con las aplicaciones ó el usuario final.

û Protocolo de terminal virtual (VTP): permite establecer comunicación entre terminales que no son iguales (capacidad, formato de pantalla, ...)

û Transferencia virtual de ficheros (FTAM): permite transferir ficheros con formatos diferentes convertidos a un fichero virtual.

û Correo universal (X.400) servicio de correo electrónico independiente de la red.

û Transferencia y manipulación de tareas (JTM): permite la ejecución de tareas en un sistema distribuido.

û Compartición de recursos

û Comunicación entre procesos

û Gestión de red

•14


27


Elementos de la Arquitectura OSI (1)

ü Sistema: conjunto de aplicaciones y recursos de comunicación.

ü Niveles o Capas: diferentes estratos en que se divide el funcionamiento de sistemas abiertos.

ü Entidades: hardware y software necesario para implementar las funciones deun determinado nivel.

ü Servicios: conjunto de capacidades que puede ofrecer un nivel al nivel superior. Son sólo servicios lo que el nivel superior ve del nivel inferior.

ü Puntos de acceso al servicio (SAP): lugar por donde un nivel presta sus servicios a un nivel superior.

ü Protocolos: juego de reglas y formatos que gobiernan las comunicaciones entre entidades que ejecutan funciones a un mismo nivel en diferentes sistemas abiertos.

ü Interfases: comunicación entre dos niveles adyacentes. Señales eléctricas,datos de control, ...


28


Elementos de la Arquitectura OSI (2)

Nivel N+1

Nivel N

Nivel N-1

Servicios N

Servicios N-1

E(N+1) E(N+1) E(N+1) E(N+1)

E(N) E(N) E(N)

E(N-1) E(N-1) E(N-1)

SAP(N)

SAP(N-1)

DTE (A) DTE (B)

Protocolo (N)

•15


29


Unidades de Transf. Información (1)

ü PDU (Unidad de datos de Protocolo):

Información que pasa al homólogo del mismo nivel de otro sistema abierto.

ü IDU (Unidad de Datos de Interfase)

Información que pasa en vertical de un nivel N al nivel N-1 por la interfase SAP.

IDU (N) = ICI (N) + SDU (N-1)

ü SDU (Unidad de Datos de Servicio)

Información lógica que pasa entre dos sistemas abiertos horizontalmente (al mismo nivel)

ü ICI (Información de Control de Interfase)

Datos de control del interfase para pasar la información en sentido vertical.

ü PCI (Información de Control de protocolo)

Datos de control de protocolo para transmitir la información en sentido horizontal.

SDU (N-1) + PCI(N-1) = PDU (N-1)

ü SAP (Punto de Acceso al Servicio)


30



ü Sin Fragmentación

ICI

ICI PDU (N)

IDU

Nivel N

Nivel N-1SDU (N-1)

SAP

PCI(N-1) SDU (N-1)

ICI PDU (N-1)

•16


31



ü Con Fragmentación

ICI

ICI PDU (N)

IDU

Nivel N

Nivel N-1SDU (N-1)

SAP

PCI(N-1) SDU1 (N-1)

ICI PDU 1 (N-1)

PCI(N-1) SDU2 (N-1)

ICI PDU 2 (N-1)


32


Protocolos ISO - WAN

•17


33


Subcapa de Señalización

802.5

TokenRing

802.3

CSMA/CD

802.4

TokenBus

Protocolos ISO - LAN (1)

ü Sigue un modelo diferente al modelo OSI ya que su arquitectura fue diseñada con anterioridad por los propios fabricantes.

ü El IEEE realizó los trabajos de normalización cubriendo normas diferentes bajo la numeración 802.x

Capa Física

Capa Enlace

Capa Red

802.2 LLC Nivel de Enlace Lógico

802.1 Relacción general con modelo OSI

MAC

.......


34


Protocolos ISO - LAN (2)

ü El modelo IEEE se diferencia fundamentalmente en los dos primerosniveles (Físico y de Enlace). Se reestructuran en tres capas:

û Medio físico de transmisión [Parte del Nivel Físico OSI]

û Control de acceso al medio (MAC) [Nivel Físico + parte del Nivel de Enlace]

û Control de enlace lógico (LLC) [Resto del nivel de enlace]

ü La capa de red es equivalente al nivel de red OSI y se encarga de manejar las diferencias con el modelo OSI hacia los niveles superiores.

ü La mayor diferencia de arquitectura es que el nivel LLC permite una comunicación extremo a extremo (esto está reservado al nivel de transporte en el modelo OSI). Esta característica permite independizar el nivel de red del tipo de red de área local que empleemos.

•18


35


Topologías LAN

ü Topologías físicas

ü Topologías lógicas


36


Familia Protocolos TCP/IP

Medio Físico

Capa Aplicación PING

Capa Transporte TCP UDP

Capa Red ICMP IP

Capa Enlace ARP Enlace

IGMP

RARP

Telnet FTP DNSBOOTPSMTP NFS/RPCHTTP SNMP

Capa Física

Capa Enlace

Capa Red

Capa Transporte

Capa Sesión

Capa Presentación

Capa Aplicación

OSI

•19


37



ü Su desarrollo fue previo al del modelo OSI

ü Las ideas básicas del modelo OSI se basaron en el modelo de capas de TCP/IP por lo que existe una gran similitud

û Los niveles más bajos correspondientes a las capas física y de enlace no están especificados ya que el protocolo se pensó para funcionar sobre cualquier tipo de red

û Los protocolos ARP y RARP se encargan de enlazar los sistemas dedireccionamiento IP y el de la red física utilizada

û La base de la familia de protocolos es el nivel de Red (Internet Protocol). Es un protocolo muy sencillo de tipo datagrama de forma que se pueda implementar en cualquier tipo de máquina.

ü A diferencia de OSI, no se distingue claramente entre servicio, interfaz y protocolo (está entremezclado)


38


Ejemplo: emisor

ü Comunicación de datos entre dos procesos corriendo en máquinas con arquitectura diferente

Capa Física: convierte la trama en señales físicas y las pone en el medio

Capa Enlace: genera una trama con la dirección física del nodo especificado y la remite, corrigiendo posibles errores

Capa Red: el mensaje es encapsulado en dos paquetes, añadiendo la dirección del hosts destino. Establece el nodo siguiente al que se debe enviar el paquete

Capa Transporte : crea un mensaje con los datos y establece la comunicación con el host destino (dirección y puerto)

Capa Presentación: Se convierte a un formato común (ASCII 8 bits)

Capa Aplicación: Proceso envía un array de caracteres UNICODE

2000 caracteres UNICODE (4000 bytes)

2000 bytes (ASCII 8bits)


Dir Puerto

1024 bytes (Total)

Dst/Fuente/Frg

512 bytes (Total)

CE

1024 bytes (Total)

Dst/Fuente/Frg

CE

512 bytes (Total)

512 bytes (Total)

CE CE 512 bytes (Total)

•20


39


Ejemplo: receptor

Capa Física: convierte la señal física en una ristra de bits

Capa Enlace: recibe la trama y comprueba que es correcta enviando un asentimiento. Reensambla las tramas

Capa Red: comprueba que la dirección de destino es la actual. Ordena y Reensambla los paquetes

Capa Transporte : recibe el mensaje, comprueba si es correcto y envía un asentimiento

Capa Presentación: Se convierte de formato ASCII 8 bits a ASCII 7 bits

Capa Aplicación: Proceso recibe cadena caracteres ASCII 7 bits

2000 caracteres ASCII 7bits (2000 bytes)

2000 bytes (ASCII

8bits)


Dir Puerto

1024 bytes (Total)

Dst/Fuente/Frg

512 bytes (Total)

CE

1024 bytes (Total)

Dst/Fuente/Frg

CE 512 bytes (Total)

512 bytes (Total)

CE CE 512 bytes (Total)


Tema IV Procesos y Threads

1

1. Introducción. 1.1. Definición de Protocolo.

Una red es una configuración de computadora que intercambia información. Pueden proceder de una variedad de fabricantes y es probable que tenga diferencias tanto en hardware como en software, para posibilitar la comunicación entre estas es necesario un conjunto de reglas formales para su interacción. A estas reglas se les denominan protocolos. Un protocolo es un conjunto de reglas establecidas entre dos dispositivos para permitir la comunicación entre ambos.

1.2. Orígenes de TCP/IP.

El Protocolo de Internet (IP) y el Protocolo de Transmisión (TCP), fueron desarrollados inicialmente en 1973 por el informático estadounidense Vinton Cerf como parte de un proyecto dirigido por el ingeniero norteamericano Robert Kahn y patrocinado por la Agencia de Programas Avanzados de Investigación (ARPA, siglas en inglés) del Departamento Estadounidense de Defensa. Internet comenzó siendo una red informática de ARPA (llamada ARPAnet) que conectaba redes de ordenadores de varias universidades y laboratorios en investigación en Estados Unidos. World Wibe Web se desarrolló en 1989 por el informático británico Timothy Berners-Lee para el Consejo Europeo de Investigación Nuclear (CERN, siglas en francés). 2. ¿Qué es TCP/IP? 2.1. Definición de TCP/IP.

TCP/IP es el protocolo común utilizado por todos los ordenadores conectados a Internet, de manera que éstos puedan comunicarse entre sí. Hay que tener en cuenta que en Internet se encuentran conectados ordenadores de clases muy diferentes y con hardware y software incompatibles en muchos casos, además de todos los medios y formas posibles de conexión. Aquí se encuentra una de las grandes ventajas del TCP/IP, pues este protocolo se encargará de que la comunicación entre todos sea posible. TCP/IP es compatible con cualquier sistema operativo y con cualquier tipo de hardware.

TCP/IP no es un único protocolo, sino que es en realidad lo que se conoce con este nombre es un conjunto de protocolos que cubren los distintos niveles del modelo OSI. Los dos protocolos más importantes son el TCP (Transmission Control Protocol) y el IP (Internet Protocol), que son los que dan nombre al conjunto.



2

2.2. Modelo general de TCP/IP.

La arquitectura del TCP/IP consta de cinco niveles o capas en las que se agrupan los protocolos, y que se relacionan con los niveles OSI de la siguiente manera:

• Aplicación: Se corresponde con los niveles OSI de aplicación, presentación y sesión. Aquí se incluyen protocolos destinados a proporcionar servicios, tales como correo electrónico (SMTP), transferencia de ficheros (FTP), conexión remota (TELNET) y otros más recientes como el protocolo HTTP (Hypertext Transfer Protocol). • Transporte: Coincide con el nivel de transporte del modelo OSI. Los protocolos de este nivel, tales como TCP y UDP, se encargan de manejar los datos y proporcionar la fiabilidad necesaria en el transporte de los mismos. • Internet: Es el nivel de red del modelo OSI. Incluye al protocolo IP, que se encarga de enviar los paquetes de información a sus destinos correspondientes. Es utilizado con esta finalidad por los protocolos del nivel de transporte, es decir, implementar protocolos extremo a extremo (entre nodo origen y destino).

• Físico: Análogo al nivel físico del OSI.

• Red: Es la interfaz de la red real. TCP/IP no especifíca ningún protocolo concreto, así es que corre por las interfaces conocidas, como por ejemplo: 802.2, CSMA/CD, X.25, etc.

FIG: Arquitectura TCP/IP



3

El TCP/IP necesita funcionar sobre algún tipo de red o de medio físico que proporcione sus propios protocolos para el nivel de enlace de Internet. Por este motivo hay que tener en cuenta que los protocolos utilizados en este nivel pueden ser muy diversos y no forman parte del conjunto TCP/IP. Sin embargo, esto no debe ser problemático puesto que una de las funciones y ventajas principales del TCP/IP es proporcionar una abstracción del medio de forma que sea posible el intercambio de información entre medios diferentes y tecnologías que inicialmente son incompatibles.

Para transmitir información a través de TCP/IP, ésta debe ser dividida en

unidades de menor tamaño. Esto proporciona grandes ventajas en el manejo de los datos que se transfieren y, por otro lado, esto es algo común en cualquier protocolo de comunicaciones. En TCP/IP cada una de estas unidades de información recibe el nombre de "datagrama" (datagram), y son conjuntos de datos que se envían como mensajes independientes.

2.3. Características de la red TCP/IP.

Ya que dentro de un sistema TCP/IP los datos transmitidos se dividen en pequeños paquetes, éstos resaltan una serie de características:

• La tarea de IP es llevar los datos a granel (los paquetes) de un sitio a

otro. Las computadoras que encuentran las vías para llevar los datos de una red a otra (denominadas enrutadores) utilizan IP para trasladar los datos. En resumen IP mueve los paquetes de datos a granel, mientras TCP se encarga del flujo y asegura que los datos estén correctos.

• Las líneas de comunicación se pueden compartir entre varios

usuarios. Cualquier tipo de paquete puede transmitirse al mismo tiempo, y se ordenará y combinará cuando llegue a su destino. Compare esto con la manera en que se transmite una conversación telefónica. Una vez que establece una conexión, se reservan algunos circuitos para usted, que no puede emplear en otra llamada, aun si deja esperando a su interlocutor por veinte minutos.

• Los datos no tienen que enviarse directamente entre dos

computadoras. Cada paquete pasa de computadora en computadora hasta llegar a su destino. Éste, claro está, es el secreto de cómo se pueden enviar datos y mensajes entre dos computadoras aunque no estén conectadas directamente entre sí. Lo que realmente sorprende es que sólo se necesitan algunos segundos para enviar un archivo de buen tamaño de una máquina a otra, aunque estén separadas por miles de kilómetros y pese a que los datos tienen que pasar por múltiples computadoras. Una de las razones de la rapidez es que, cuando algo anda mal, sólo es necesario volver a transmitir un paquete, no todo el mensaje.



4

• Los paquetes no necesitan seguir la misma trayectoria. La red puede llevar cada paquete de un lugar a otro y usar la conexión más idónea que esté disponible en ese instante. No todos los paquetes de los mensajes tienen que viajar, necesariamente, por la misma ruta, ni necesariamente tienen que llegar todos al mismo tiempo.

• La flexibilidad del sistema lo hace muy confiable. Si un enlace se

pierde, el sistema usa otro. Cuando usted envía un mensaje, el TCP divide los datos en paquetes, ordena éstos en secuencia, agrega cierta información para control de errores y después los lanza hacia fuera, y los distribuye. En el otro extremo, el TCP recibe los paquetes, verifica si hay errores y los vuelve a combinar para convertirlos en los datos originales. De haber error en algún punto, el programa TCP destino envía un mensaje solicitando que se vuelvan a enviar determinados paquetes.

3. Direccionamiento IPv4. 3.1. Jerarquía de clases en las direcciones IPv4.

El protocolo IP identifica a cada ordenador que se encuentre conectado a

la red mediante su correspondiente dirección. Esta dirección es un número de 32 bits que debe ser único para cada host, y normalmente suele representarse como cuatro cifras de 8 bits separadas por puntos.

La dirección de Internet (IP Address) se utiliza para identificar tanto al

ordenador en concreto como la red a la que pertenece, de manera que sea posible distinguir a los ordenadores que se encuentran conectados a una misma red. Con este propósito, y teniendo en cuenta que en Internet se encuentran conectadas redes de tamaños muy diversos, se establecieron tres clases diferentes de direcciones, las cuales se representan mediante tres rangos de valores:

Direcciones de Clase A. Son las que en su primer byte tienen un valor comprendido entre 1 y

126, incluyendo ambos valores. Estas direcciones utilizan únicamente este primer byte para identificar la red, quedando los otros tres bytes disponibles para cada uno de los hosts que pertenezcan a esta misma red. Esto significa que podrán existir más de dieciséis millones de ordenadores en cada una de las redes de esta clase. Este tipo de direcciones es usado por redes muy extensas, pero hay que tener en cuenta que sólo puede haber 126 redes de este tamaño. ARPAnet es una de ellas, existiendo además algunas grandes redes comerciales, aunque son pocas las organizaciones que obtienen una dirección de "clase A". Lo normal para las grandes organizaciones es que utilicen una o varias redes de "clase B".



5

Direcciones de Clase B. Estas direcciones utilizan en su primer byte un valor comprendido entre

128 y 191, incluyendo ambos. En este caso el identificador de la red se obtiene de los dos primeros bytes de la dirección, teniendo que ser un valor entre 128.1 y 191.254 (no es posible utilizar los valores 0 y 255 por tener un significado especial). Los dos últimos bytes de la dirección constituyen el identificador del host o nodo permitiendo, por consiguiente, un número máximo de 64516 ordenadores en la misma red. Este tipo de direcciones tendría que ser suficiente para la gran mayoría de las organizaciones grandes. En caso de que el número de ordenadores que se necesita conectar fuese mayor, sería posible obtener más de una dirección de "clase B", evitando de esta forma el uso de una de "clase A".

Direcciones de Clase C. En este caso el valor del primer byte tendrá que estar comprendido entre

192 y 223, incluyendo ambos valores. Este tercer tipo de direcciones utiliza los tres primeros bytes para el número de la red, con un rango desde 192.1.1 hasta 223.254.254. De esta manera queda libre un byte para el nodo, lo que permite que se conecten un máximo de 254 ordenadores en cada red. Estas direcciones permiten un menor número de host o nodos que las anteriores, aunque son las más numerosas pudiendo existir un gran número redes de este tipo (más de dos millones).

Se identifican porque el bit más significativo vale 0

Este campo puede ir delante o detrás, dependiendo del computador. Por esto es necesario que existan funciones que realicen el cambio sin dar lugar a errores.

Se identifican porque los bits más significativos valen 10



6

Direcciones de Clase D. Estas se identifican porque los cuatro bits más significativos tienen la

combinación 1110. Se emplean para enviar datos de forma simultánea a computadoras que no tiene por qué pertenecer a la misma red o subred.

Direcciones de ClaseE. Estas se identifican porque los cinco bits más significativos tienen la

combinación 11110. Los valores disponibles están reservados para futuras ampliaciones.

Las siguientes tablas resumen los rangos de valores para cada clase así

como los rangos de direcciones que están reservados para su uso en redes privadas.

Rangos de direcciones IP

Clase Nodos por

clase Máscara

Dirección de comienzo

Dirección final

A 16.777.216 255.0.0.0 0.0.0.0 127.255.255.255 B 65.536 255.255.0.0 128.0.0.0 191.255.255.255 C 256 255.255.255.0 192.0.0.0 223.255.255.255 D - - 224.0.0.0 239.255.255.255 E - - 240.0.0.0 240.255.255.255

Rangos de direcciones IP reservadas

Clase Máscara Dirección de

comienzo Dirección final

A 255.0.0.0 10.0.0.0 10.255.255.255 B 255.255.0.0 172.0.0.0 191.31.255.255 C 255.255.255.0 192.168.0.0 192.168.255.255

Se identifican porque los bits más significativos valen 110



7

3.2. Máscara de subred.

Ésta es de suma importancia ya que determina si un paquete de datos va dirigido a una máquina ubicada en la misma red local o debe ser encaminada a través de un enrutador para alcanzar su destino final y así minimizar el tráfico de información. Por tanto, se puede decir que el objetivo de la máscara es evitar que una comunicación entre dos máquinas cercanas use los recursos de la red completa (sino fuese así un paquete tendría que llegar a cada uno de los computadores de la red a pesar de que ambos se encuentren en el mismo segmento de red).

Por lo tanto, si la dirección destino está dentro de la misma subred, el

paquete se coloca en el segmento de red local y si no, se envía en un encaminador que remite dicha información a todos los segmentos de la red.

Los bits de la máscara de subred especifican si el bit correspondiente a

una dirección IP especifica una red o una máquina. A cada clase le corresponde una máscara distinta puesto que, por ejemplo, una red de clase A tendrá los ocho primeros bits a 1, una de clase B tendrá los 16 primeros a 1 y una de clase C tendrá los 24 primeros a 1 tal y como podemos observar en la siguiente figura.

En el siguiente ejemplo se puede observar todo este mecanismo

empleado por IP.



8

Otra de las ventajas que ofrece el direccionamiento IP es el uso de direcciones de difusión (broadcast addresses), que hacen referencia a todos los host de la misma red. Según el estándar, cualquier dirección local (hostid) compuesta toda por 1s está reservada para difusión (broadcast). Por ejemplo, una dirección que contenga 32 1s se considera un mensaje difundido a todas las redes y a todos los dispositivos. Es posible difundir en todas las máquinas de una red alterando a 1s toda la dirección local o de anfitrión (hostid), de manera que la dirección 147.10.255.255 para una red de Clase B se recibiría en todos los dispositivos de dicha red ; pero los datos no saldrían de dicha red.

Ejemplos prácticos:

EJEMPLO I

Consideremos la siguiente dirección IP en binario: 11001100.00001000.00000000.10101010 (204.8.0.170) La dirección de la máscara (MASK) es en binario : 11111111.11111111.11100000.00000000 (255.255.224.0)

Según lo visto anteriormente, para hallar la dirección se SubRED (SubNet)

realizamos la operación AND, es decir, tomamos la IP y considerando que todo lo que tenga 1s en la máscara se queda como esta en la IP, y todo lo que tenga 0s en la mascara se pone a 0 en la IP. Entonces, la dirección de SubRed es:

11001100.00001000.00000000.10101010 (204.8.0.170) 11111111.11111111.11100000.00000000 (255.255.224.0) 11001100.00001000.00000000.00000000 (204.8.0.0)



9

EJEMPLO II

Sea la dirección IP en binario y la máscara de red: 00001001.01000011.00100110.00000000 (9.67.38.0) 11111111.11111111.11111111.11000000 (255.255.255.19 2) Siguiendo el criterio anterior, tenemos que la dirección de SubNet es: 00001001.01000011.00100110.00000000 (9.67.38.0)

En la dirección de la máscara de red, los últimos 6 bits han quedado a 0. Estos bits son los que definen las máquinas de la SubRed (26=64). De estas 64 máquinas quitamos la última de ellas (será para el Broadcast). Por tanto tendremos:

SubNet Ardes

-9.67.38.1 1ª máquina de la SubRed -9.67.38.2 2ª máquina de la SubRed ......... -9.67.38.62 última máquina de la SubRed

-9.67.38.63 BROADCAST

EJEMPLO III

Sea la dir.IP la 201.222.5.121, la dirección de máscara 255.255.255.248,

Entonces, haciendo los correspondientes cálculos en binario tenemos que:

201.222.5.121 (IP address)

201.222.5.248 (NET MASK)

201.222.5.120 (SubNet addr.)

En la dirección de máscara, el 248 es 0111000, por tanto los últimos 3 bits a 0 son destinados para las máquinas de red (2^3=8), por tanto habrá 6 máquinas:

201.222.5.120 SubNet ardes

201.222.5.121 1ª máquina de la Subset 201.222.5.122 2ª máquina de la Subset

............. 201.222.5.126 última máquina de la subset 201.222.5.127 BROADCAST

9.67.38.0



10

EJEMPLO IV

15.16.193.6 (IP addr.)

255.255.248.0 (Net MASK), el SubNet addr. Será :

15.16.192.0 y como en la máscara de red 248.0 es 11111000.00000000

Tendremos por tanto 2^11=2048, lo que implica que tenemos 2046 máquinas en la Subred:

15.16.192.0 SubNet ardes 15.16.192.1 1ª máquina de la Subred

15.16.192.2 2ª máquina de la Subred 15.16.192.3

............ 15.16.200.254 última máquina de la subred 15.16.200.255 BROADCAST

3.3. Direcciones reservadas.

Existen dos especificaciones reservadas que son las dos siguientes

combinaciones:

• Si la combinación es de todos los bits a o se identifica a la red o subred. Es empleada para el enrutamiento y así poder referirse a todas las máquinas de la red.

• La dirección con todos los bits a 1 indica una dirección de

broadcast utilizada para enviar un paquete de datos a todas las máquinas de la red.

También existe otra dirección especial conocida como loopback Driver

caracterizada por permitir que los procesos origen y destino estén ubicados en el mismo computador, actuando como si realmente estuvieran en una red. Se identifica mediante la red 127 (127.0.0.0).

La dirección 0.0.0.0 es usada por los computadores cuando están siendo

arrancados y no conocen todavía su dirección IP permitiendo a las máquinas referirse a la red sin saber su número.

En el dibujo se puede observar que cuando un proceso quiere

comunicarse con otro que tiene asignada su misma dirección IP la capa de red (IP) intercepta dicha información y la reenvía al proceso destina de la capa transporte. La diferencia entre ambos radicará en el puerto asignado.



11

3.4. Direccionamiento CIDR.

•1

1

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP

SITR RedesSITR RedesISA-UMH ©

Objetivos

n Describir y analizar la familia de protocolos TCP-IPn ¿Qué vamos a estudiar?

n Direccionamiento MAC/IP. n Protocolos ARP, RARPn Protocolo de señalización ICMPn Protocolo de red IP.n Protocolos de transporte TCP/UDP.

n Documentación adicionaln RFC (Request For Comments): http://www.rfc-

editor.org/rfc.htmln “TCP/IP Illustrated. Vol.1” W.R. Stevens, Addsion Wesley

2

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP



Medio Físico

Capa Aplicación PING

Capa Transporte TCP UDP

Capa Red ICMP IP

Capa Enlace ARP Enlace

IGMP

RARP

Telnet FTP DNSBOOTPSMTP NFS/RPCHTTP SNMP

•2

3

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Protocolos (1)

n El origen de esta familia de protocolos fue la red ARPANET (en ella se desarrollaron los conceptos fundamentales de diseño y gestión de redes)

n Los niveles más bajos (enlace y físico) no están implementados ya que se diseñó para no depender de una red física concretan Los protocolos ARP (Adress Resolution Protocol) y RARP

(Reverse Adress Resolution Protocol) se encargan de enlazar los sistemas de direccionamiento IP y el de la red física utilizada

4

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Protocolos (2)

n Capa de Red:n La base de la familia de protocolos es el nivel de Red (Internet

Protocol). Es un protocolo de conmutación de paquetes muy sencillo, de tipo datagrama, de forma que se pueda implementar en cualquier tipo de máquina.

n A diferencia de OSI, no se distingue claramente entre servicio, interfaz y protocolo (está entremezclado)

n Existen actualmente dos versiones IPv4, IPv6n Protocolos de apoyo:

n ICMP (Internet Control Message Protocol) : comunicación de mensajes entre nodos de la red

n IGMP (Internet Group Mangement Protocol) : envío de mensajes a grupos de usuarios

•3

5

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Protocolos (3)

n La capa de transporte:n Implementa protocolos extremo a extremo (entre

nodo origen y destino de la información). Se definen dos protocolos:

n TCP (Transmission Control Protocol): n Es un protocolo orientado a la conexión con control de erroresn Se encarga también del control de flujon Troceado y reensamblado de flujos (garantía de

secuenciamiento)

n UDP (User Datagram Protocol) :n Es un protocolo sin conexión (datagrama)n No realiza control de erroresn No garantiza el secuenciamiento de la informaciónn Es muy rápidon Util para peticiones aisladas, o transmisión de audio o vídeo.

6

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Protocolos (4)

n Capa Aplicación: (protocolos de alto nivel)n Protocolos basados en ICMP:

n PING : solicitud de eco

n Protocolos basados en TCP:n TELNET: terminal remoton FTP (File Transfer Protocol): transmisión de ficherosn SMTP (Simple Mail Transfer Protocol): correo electrónicon HTTP (HyperText Transfer Protocol: páginas webn RPC (Remote Procedure Call): ejecución de procesos remotos

n Protocolos basados en UDP:n SNMP (Simple Network Management Protocol): gestión de redn BOOTP : arranque remoton DNS (Domain Name System)n RPC (Remote Procedure Call): ejecución de procesos remotos

n NFS/RPC (Network File System) (gestión de ficheros en red)

•4

7

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Direccionamiento IPv4 (1)

n Las direcciones IPv4 tienen una longitud de 32 bits (4 bytes)n Tienen dos partes :

n Parte de redn Parte de subred/nodo

n Clases de direcciones:n Clase A

n Clase B

n Clase C

0xxx xxxx . xxxxxxxx . xxxxxxxx xxxxxxxx.

Red Subred/Nodo

1111 1111 . 0 . 0 . 0 Máscara

10xx xxxx . xxxxxxxx . xxxxxxxx xxxxxxxx.

Red Subred/Nodo

1111 1111 . 1111 1111 . 0 . 0 Máscara

110x xxxx . xxxxxxxx . xxxxxxxx xxxxxxxx.

Red Subred/Nodo

1111 1111 . 1111 1111 . 1111 1111 . 0 Máscara

8

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP



n Clase D

n Clase E

1110 xxxx . xxxxxxxx . xxxxxxxx xxxxxxxx.

Multicast (28 bits)

11110 xxx . xxxxxxxx . xxxxxxxx xxxxxxxx.

Futuras ampliaciones (27 bits)

Clase Nodos porclase

Máscara Dir.Comienzo

Dir. final

A 16.777.216 255.0.0.0 0.0.0.0 127.255.255.255B 65536 255.255.0.0 128.0.0.0 191.255.255.255C 256 255.255.255.0 192.0.0.0 223.255.255.255D - - 224.0.0.0 239.255.255.255E - - 240.0.0.0 255.255.255.255

Clase Máscara Dir. Comienzo Dir. FinalA 255.0.0.0 10.0.0.0 10.255.255.2555B 255.255.0.0 172.16.0.0 191.31.255.255C 255.255.255.0 192.168.0.0 192.168.255.255

Rangos de direcciones IP reservadas

Rangos de direcciones IP

•5

9

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP



n Máscara de Subred: n Una red se puede dividir en subredesn El campo de Subred/Máquina se puede dividir en:

n Direccionamiento de subredesn Direccionamiento de máquinas (dentro de la subred)

n Ejemplo:

10xx xxxx . xxxxxxxx . xxxxxxxx xxxxxxxx.

Red Nodo

1111 1111 . 1111 1111 . 11111111 . 0 Máscara

Subred

Máscara de Subred (permite calcular si un paquete debe ser enviado fuera de la subred)147. 125. 3. 5

Red clase B 147.125

Máquina 5

Subred 3

Clase B

10

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP



n Utilización de la máscara de red:

147.123.3.0 147.123.6.0

147.123.6.6711111111 .11111111.11111111 . 0

Dirección IP adaptador origen

147.123.3.5

Dirección IP destinoMáscara

ANDAND

0. 0. 5 .0

XORSi el resultado es 0 pertenecen a la misma subred.

El valor 5 indica que pertenecen a subredes diferentes

•6

11

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP



n Direccionamiento de máquinan Existen dos valores de los bits del campo de máquina

reservados:n 0000 0000 (todos los bits a 0) identifica la red/subredn 1111 1111 (todos los bits a 1) dirección de broadcast

(envío simultáneo de paquetes a todas las máquinas conectadas a la subred)

Por seguridad el uso de paquetes de broadcast está limitado a la subred.

n Ejemplo:147. 125. 3. 0 Identificador de la subred 147.125.3

147. 125. 3. 255 Paquete de broadcast a toda la subred 147.125.3

Clase C

12

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP



n Bucle local (Loopback Driver):n Es una interface que permite a un cliente y un servidor

estar situados en la misma máquina.n Se reserva el identificador de red 127.n Generalmente se usa la dirección 127.0.0.1n Se le asigna el nombre ‘localhost’

TCP

IP

Mensaje destino194.136.32.1

Mensaje a Loopback Driver

Mensaje 127.0.0.1

IP 194.136.32.1

•7

13

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Direccionamiento IPv4 CIDRn Implementa un método de enrutamiento interdominios

sin clases (RFC 1519)n Las redes de clase B son demasiado grandes y las de

clase C son demasiado pequeñasn CIDR permite unir varias redes de clase C contiguas,

marcando los bits de la máscara de red como máquina (bit a 0)

n Están clasificados por regiones para facilitar las tareas de enrutamiento

Región Dir. Comienzo Dir. finalEuropa 194.0.0.0 195.255.255.255

Norteamérica 198.0.0.0 199.255.255.255Centro y Sudamérica 200.0.0.0 201.255.255.255

Asia y Pacífico 202.0.0.0 203.255.255.255Reserva 204.0.0.0 205.255.255.255

194 . 169 . xxxxxxxx.

Red Nodo

1111 1111 . 1111 1111 . 1111 1100 . 000 0000 Máscara

Bits CIDRUnión de redes Clase C

1000 10xx

14

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Nivel de Enlace LLC/MAC (1)

n Como comentamos, TCP/IP no define el nivel de enlacen Estudiaremos un caso muy usual: disponer de un

adaptador de Red Ethernetn Existen dos tipos de tramas :

n IEEE 802.2/802.3n Ethernet

Encapsulación Ethernet (RFC 894)

MAC -Destino

MAC-Fuente

Tipo

6 6 2 4

CRCDatos: Datagrama IP

46 - 1500

Cabecera

21 311

DSAP

Encapsulación IEEE 802.2/802.3 (RFC 1042)

MAC -Destino

MAC -Fuente

Long.

6 6 2 4

CRCDatos: Datagrama IP

38-1492

SSAP Cntl Org. Code

Tipo

Cabecera

•8

15

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Nivel de Enlace LLC/MAC (2)

n MTU (Maximun Transmission Unit)n Depende del tipo de adpatador de redn Si un datagrama IP es mayor que el MTU se fragmenta

(a nivel IP)n Se puede averiguar ejecutando el comando ‘netstat -i’

$ netstat -i

Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queuelo0 8232 loopback localhost 1375284 0 1375284 0 0 0

hme0 1500 lorca lorca 7246270 70 6586492 1 619142 0

16

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Direccionamiento MAC

n Para que un datagrama IP alcance su destino es preciso conocer su dirección física

n Se trata de una combinación de 48 bits agrupados en 6 bytes,

n Los tres primeros bytes identifican al fabricanten Los tres últimos bytes identifican la tarjetan La dirección MAC es única e irrepetiblen Existe una dirección reservada que tiene todos los bits a

1 FF:FF:FF:FF:FF:FF, se utiliza para enviar una trama a todas las máquinas de la red (broadcast)

02:60:8C:0D:0A:5C

Fabricante: 3Com

•9

17

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Direccionamiento MAC

n Para conocer la dirección MAC propia basta con interrogar al adaptador de redn Windows 95: ejecutar winipcfgn Windows NT 4.0: ejecutar ipconfig

n Para enviar un datagrama necesitamos también la dirección MAC de destino.

n Protocolo ARP (Address Resoultion Protocol) obtiene la dirección MAC correspondiente a una dirección IPn Envía una trama de ‘Petición ARP’ a todas las máquinas de la red

(broadcast)n El protocolo ARP de la máquina destino verifica que el solicitante

pide su dirección IP.n Emite una trama de ‘Respuesta ARP’ incorporando su dirección

MAC e IPn Se recibe la respuesta guardando el resultado en una tabla,

pudiendo emitir a partir de entonces datagramas IP

18

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Protocolo ARP (1)

Cabecera Ethernet

62 2

MAC -DST

MAC-SRC

Type

6 6 2 2 64 41 1

Hardtype

Prottype

Hard Size

Prot Size

OPSndMAC Addr

TargetMAC Addr

SndIP Addr

TargetIP Addr

Type: 0x0806 (trama ARP)

Hard type: 1 (Ethernet)Prot. type: 0x0800 (IP)

Hard size: 6 (bytes dir. MAC)Prot size: 4 (bytes dir. IP)

OP: tipo de operación

1: ARP request2: ARP reply

3: RARP request4: RARP reply

02:60:8C:0D:0A:5C192.147.136.7 192.147.136.8 192.147.136.9

02:60:8C:0D:0A:5E02:60:8C:0D:0A:5D

ARP Request 192.147.136.9 (Broadcast )

ARP Reply(02:60:8C:0D:0A:5E )

TRAMA ARP

•10

19

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Protocolo ARP (2)

n Los datos se almacenan en una tabla dinámica:n el comando arp -a nos muestra la tabla de ARP con la relación

entre direcciones MAC e IPn El plazo normal de expiración de una entrada es de 20

minutos después de su creación

n El Protocolo RARP (Reverse Address Resolution Protocol) se utiliza para obtener una dirección IP en sistemas sin disco duro.

$ arp -aNet to Media TableDevice IP Address Mask Flags Phys Addr------ -------------------- --------------- ----- ---------------hme0 193.147.136.216 255.255.255.255 00:60:08:64:39:07hme0 193.147.136.1 255.255.255.255 00:e0:1e:3d:fe:83hme0 192.168.2.20 255.255.255.255 00:a0:c9:78:75:bbhme0 lorca 255.255.255.255 SP 08:00:20:a2:55:fe

hme0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01:00:5e:00:00:00

20

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Protocolo ICMP (1)

n Tiene como misión comunicar los mensajes de error, solicitudes y respuestas entre nodos de la red (RFC 792)

n Los mensajes son enviados dentro de un datagrama IP

Tipo (Error):

3: Destino Inaccesible4: cadencia demasiado elevada

5: Redirección11: Tiempo sobrepasado (TTL)

12: Problema de parámetros o forma

Mensaje ICMPTipo (Solicitud):0: Respuesta de eco (Ping)

8: Petición de eco (Ping)9: Aviso de Router10: Solicitud de Router13: Petición ‘timestamp’14: Respuesta ‘timestamp’15: Pet. de información (obsoleto)16: Resp . de información (obsoleto)17: Petición máscara dirección18: Respuesta máscara dirección

Código:0: Solicitud

X: Especifica diferentes tipos de errores

Datagrama IP

1 2

Cabecera IP

20 (20-64 Grabación de ruta)

1 variable

Tipo Código SVT Checksum Extra: Según el tipo de mensaje

•11

21

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Protocolo ICMP (2)

n Existen dos tipos de mensajes:n Solicitud ICMP:

n Se solicita o se informa de un acontecimiento concreto que no es causa de ningún error

n Ejemplo: el envío de un eco, o la presencia de un router

n Notificación de Error ICMP: n Por ejemplo: una máquina inaccesible, una fragmentación

requerida, etc...n Un mensaje de error no puede ser producido por otro

mensaje de errorn Un mensaje de error contiene siempre la cabecera IP (20

bytes) y los 8 primeros bytes del datagrama que lo provocó (permite asociar el mensaje a un protocolo TCP/UDP y un puerto (usuario))

22

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Protocolo ICMP (3)

n Situaciones que no producen un mensaje de error(evita las tormentas de ‘broadcast’):n Un mensaje de error ICMPn Un datagrama IP o una trama enlace destinado a una

dirección ‘broadcast’n Un fragmento recibido fuera de secuencian Un datagrama cuya dirección fuente no ha sido emitida por

una sola máquina

•12

23

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Protocolo IPv4

n Datagrama IP (RFC 791)n El tamaño normal de la cabecera es de 20 bytes, a no

ser que presente opcionesn El tamaño máximo del datagrama se ajusta para que

quepa en el MTU del nivel de enlace.Datagrama IP

0

Datos

15 16 31 bits

Opciones (si existen) múltiplo de 32 bits

Ver 4 bits HL 4 bits TOS 8 bits

Fragment Offset 13 bits

Longitud Total 16 bits

Identificación 16 bitsFlag3 bits

Protocolo 8 bitsTTL 8 bits Suma de Control de cabecera 16 bits

Dirección IP Fuente 32 bits

Dirección IP Destino 32 bits

Cabecera

24

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Cabecera IPv4 (1)

n Ver: indica la versión (4)n HL: longitud de la cabecera en palabras (4 bytes), normalmente vale

5 (20 bytes) pero puede alcanzar las 15 palabras (60 bytes) cuando se utilizan las opciones de marcado de rutas.

n TOS: Tipo de servicio. Los tres primeros bits son ignorados, los 4 bits siguientes representan el TOS y el último vale siempre 0.n Cada bit selecciona un tipo de comportamiento (solo uno puede estar

activado):n 1: Minimiza el Retardon 2: Minimiza el Caudaln 3: Maximiza la fiabilidadn 4: Minimiza Coste

n Si todos están a 0 significa servicio normaln Longitud Total: tamaño en bytes del datagrama IP incluyendo la

cabecera (máximo valor 65535)

•13

25

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Cabecera IPv4 (2)

n Identificación:permite marcar de forma única cada datagramaenviado por una máquina (16 bits) n Asegura la secuenciaciónn Asociado al mecanismo de fragmentación, su valor se copia en todos los

trozos de datagrama que componen el datagrama original)n Flag:

n El tercer bit indica (si está a uno) que hay fragmentación ‘more fragments’ (se fragmenta si se ha superado el MTU)

n El último fragmento coloca el bit a 0n El segundo bit del capo Flag se denomina ‘don’t fragment’. Si está

activado, fuerza un mensaje de error si el datagrama debe ser fragmentado y lo elimina.

n Fragment Offset: n Índice del fragmento a partir del datagrama original (en bloques de 8

bytes)n El campo longitud total es reajustado al tamaño de cada fragmenton Cada fragmento lleva su propia cabecera IP pero con el mismo

identificador de datagrama

26

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Cabecera IPv4 (3)

n TTL: (Time To Live) tiempo de expiración del datagraman Cada nodo por el que pasa decrementa este campon Si alcanza el valor 0 el datagrama es destruido y se genera un mensaje

ICMPn Permite evitar que un datagrama se quede atrapado en un bucle.

n Protocolo: identifica el protocolo de que utiliza el datagrama IPn TCP, UDP, ICMP, IGMP, ....

n Suma de Control: (suma complemento a 1 de palabras de 16 bits) n Permite comprobar errores en la cabecera (no tiene en cuenta los datos)

n Direcciones IP fuente y destinon Opciones:

n Permiten almacenar un registro de rutas, grabación de tiempos de paso por los routers, restricciones de seguridad, especificar la ruta, ...

n Está limitado a 40 bytes

•14

27

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Enrutamiento IP (1)

n Mecanismo:

$ netstat -rn

Routing Table:Destination Gateway Flags Ref Use Interface

-------------------- -------------------- ----- ----- ------ ---------193.147.136.0 193.147.136.16 U 3 2619 hme0224.0.0.0 193.147.136.16 U 3 0 hme0default 193.147.136.1 UG 0 12386

127.0.0.1 127.0.0.1 UH 01300499 lo0

¿ Para mi ?

¿ Para mi red ?

¿Tengo ruta específica?

¿Tengo ruta por omisión?

Sin ruta

Enviar al Gateway

Enviar a través de ARP

Mantenerlo

Enviar al Gateway

Host localSi

Si

Si

Si

Host conectado directamente

Hostremoto

Ruta al hostremoto

No

No

No

No

28

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Enrutamiento IP (2)

n Tabla de Rutas:n Dirección IP destino: máquina o una redn Dirección IP del siguiente router: al que se debe enviar

el datagraman Flags:

n G la dirección de IP de destino es una red (ruta indirecta)n H la dirección de IP de destino es una máquina (ruta

directa)n U la ruta está en servicion D la ruta ha sido creada por redirecciónn M ruta modificada por redirección

n Debe existir una ruta por defecto (default gateway)

•15

29

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Enrutamiento IP (3)

n Algoritmos de enrutamiento:n Se pueden crear rutas manualmente (estático)

n Se utiliza el comando ‘route ’

n La tabla de enrutamiento se actualiza también dinámicamente (demonios ‘routed’ y ‘gated’)

n Existen diferentes algoritmos según el tipo de ruta (se basan todos ellos en el intercambio de las tablas entre routers):n RIP (Routing Information Protocol):

n Usa una métrica basada en saltos (rutas corta, 16 saltos)n Utiliza datagramas UDP para pasar la información entre routers

n HELLO: usa una métrica basada en retardos (rutas largas)n BGP (Border Gateway Protocol)n EGP (Exterior Border Protocol)

30

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Capa Transporte: UDP

n UDP es un protocolo no orientado a la conexiónn Cada operación de salida efectuada por un proceso

genera un único datagrama UDPn Cada datagrama es autocontenido, no se mezclan.n Cada datagrama UDP genera un datagrama IP aunque

este puede ser fragmentado dependiendo del MTUn UDP no ofrece garantía de secuencia (los datagramas

pueden llegar desordenados)n UDP no ofrece garantía de fiabilidad(los datagramas

pueden ser incorrectos o no llegar)n UDP no ofrece control de flujon Es misión del protocolo de nivel aplicación el control de

flujo y errores

•16

31

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Datagrama UDP

Datagrama UDP0

Datos

15 16 31 bits

Número Puerto Fuente 16 bits

Longitud UDP 16 bits(cabecera + datos en bytes)

Suma de Control 16 bits(cabecera + datos)

Cabecera

UDP

Datagrama IP

8

Cabecera IP

20 variable

CabeceraUDP

Datos UDP

Número Puerto Destino 16 bits

32

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Capa Transporte: TCP (1)

n Servicio de flujo (stream) de bytes, orientado a la conexión y fiablen Precisa una etapa previa de conexión y una posterior de

desconexión a la transmisión de datosn El tamaño de los mensajes es fijado por TCP (si el

mensaje es más grande se fragmenta)n La unidad de información se denomina ‘segmento’n No hay fronteras entre mensajes

•17

33

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP



n Es un protocolo de ventana deslizante no selectivon Cuando TCP emite un segmento, mantiene un temporizador

esperando su asentimiento por el otro extremo. Si expira el temporizador se reenvía el segmento

n Si TCP recibe datos del otro extremo de la conexión, emite un asentimiento

n TCP mantiene una suma de control en su cabecera y datos. Si aparece un segmento inválido, se rechaza y no se emite asentimiento

n Los segmentos TCP son enviados como datagramas IP, por tanto pueden llegar desordenados. Los segmentos TCP llevan un número de secuencia por lo que TCP los reordena si es necesario.

34

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP



n Los segmentos TCP pueden llegar duplicados. TCP los elimina

n TCP proporciona un control de flujo (tamaño de la ventana). Adecua emisor rápido con un receptor lento

n Una conexión TCP actúa como un flujo de bytes. TCP no interpreta su contenido

1 2 873 4 5 6 2 3 4 9 100

1 873 4 5 6 2 3 4 9 100 E

Error

Paquetes 2 a 8 pasados a nivel aplicación

Almacenados en el buffer de la ventana del receptor

ACK

0

ACK

1

ACK

1

ACK

1

ACK

1

ACK

1

ACK

1

ACK

1

ACK

8

ACK

8

ACK

8

ACK

9

ACK

10

Paquetes duplicados

Intervalo Temporizador

•18

35

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Segmento TCP

Segmento TCP0

Datos

15 16 31 bits

Número Puerto Fuente 16 bitsCabecera

TCP

Datagrama IP

20

Cabecera IP

20 variable

CabeceraTCP

Datos TCP

Número Puerto Destino 16 bits

Número de secuencia (32 bits)

Número de asentimiento (segmento esperado) (32 bits)

Opciones (si existen) múltiplo de 32 bits

Suma de Control 16 bits(cabecera + datos)

Tamaño ventana 16 bits

Puntero urgente 16 bits

SYN

FIN

PSH

RST

ACK

URG

Long. Cabecera4 bits

Reservado6 bits

36

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Cabecera TCP

n Tipos de trama:n SYN : establecimiento de la conexión

n ACK : indica que incorpora un asentimiento (se aprovecha la transmisión de datos para emitir los asentimientos

n URG : indica que el puntero urgente es válido (offset que se debe añadir al número de secuencia)

n PSH :el receptor debe pasar los datos a la aplicación tan rápido como pueda

n RST : reiniciar la conexiónn FIN : el emisor finaliza la emisión de datos

•19

37

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Opciones TCP

n Opciones:

Fin de lista de opciones

Tipo=0

1 byte

Operación nula Tipo=1

1 byte

Tamaño máximo de segmento

Tipo=2

1 byte

Factor de escala de la ventana

Tipo=3

1 byte

Grabación de Tiempo

Tipo=8

1 byte

long=4

1 byte

Tamaño máximo segmento (MSS)

2 bytes

long=3

1 byte

valor

1 byte

long = 10

1 byte

Valor tiempo

4 bytes

tiempo respuesta de eco

4 bytes

38

Pro

toco

los

TC

P/IP

Pro

toco

los

TC

P/IP


Conexión-Desconexión TCPEstablecimiento conexión TCP

Equipo A Equipo B

Petición Conexión

Indicación Conexión

Confirmación Conexión

Datos

Aceptación Conexión

Petición DesconexiónIndicación Desconexión

Indicación Desconexión

Segmento 1 SYN, ISN, mss

SYN,ACK, ISN, mss Segmento 2

Segmento 3 ACK, datos

FIN, ACK

FIN, ACK

ACK

Petición Desconexión

Confirmación Desconexión

Aceptación Desconexión

Datos

Confirmación Desconexión ACKAceptación Desconexión

•1


1

SITR: RedesSOCKETS

Objetivos

ü Diseño de aplicaciones distribuidas

ü ¿Qué vamos a estudiar?û Arquitectura Cliente-Servidorû Interfaz de Sockets BSD (identificadores de procesos)

û Familias de Protocolos y Direccionesû Estructuras de datos y funciones de manejo de direccionesû Sockets de tipo Datagramaû Sockets de tipo Stream (orientados a la conexión)û Servidores MonoThread y MultiThread


2

SITR: RedesSOCKETS

Interfaz de comunicaciones

ü La arquitectura utilizada es un arquitectura Cliente-Servidorû Un proceso servidor está esperando peticiones, proporcionado un servicio cuando

este es solicitado

û Un proceso cliente comunica una petición a un servidor solicitando un servicio

û Cada proceso servidor tiene asociado un puerto (identificador único)

û Cualquier cliente utiliza el puerto para comunicarse con el servidor

ü Existen diferentes interfases de programación:û SOCKETS (BSD UNIX)û TLI (Transport Layer Interface)

û RPC (Remote Procedure Call)

Nos centraremos en el estudio de la interfaz de sockets

Servidor

cliente

cliente

•2


3

SITR: RedesSOCKETS

Interfaz de Sockets (1)

ü Cada proceso servidor y cliente tienen asociado un puerto (identificador único)

û TCP y UDP tienen su propios puertos aunque usen el mismo identificador

ü Existe una serie de puertos reservados que gestionan los protocolos de aplicación estandarizados

ü El fichero /etc/services almacena una tabla con los puertos y los procesos asignados

# Network services, Internet style ( extracto de /etc/services)nntp 19/tcp usenet # Network News Transferntp 123/tcp # Network Time Protocolntp 123/udp # Network Time ProtocolNeWS 144/tcp news # Window Systemexec 512/tcplogin 513/tcpshell 514/tcp cmd # no passwords usedprinter 515/tcp spooler # line printer spoolercourier 530/tcp rpc # experimentaluucp 540/tcp uucpd # uucp daemonbiff 512/udp comsatwho 513/udp whodsyslog 514/udptalk 517/udproute 520/udp router routedsunrpc 111/udp rpcbindsunrpc 111/tcp rpcbindtftp 69/udp


4

SITR: RedesSOCKETS


ü El socket es el mecanismo de comunicación básico que encapsula la información necesaria para establecer una comunicación entre dosprocesos:

ü Presentan una interfaz igual a la de cualquier dispositivo UNIX (ficheros, consola, ....)

Dir. IP fuente

Puerto fuente

Dir. IP destino

Puerto destino

SOCKET

Protocolo TCP/UDP

•3


5

SITR: RedesSOCKETS


ü Dominios (Protocol Family): û Familia de protocolos para conseguir el intercambio de datos entre sockets

û PF_UNIX: dominio UNIX• Comunicación entre procesos en una misma máquina

• Utilizan manejadores de ficheros

û PF_INET: dominio INET• Comunicación entre procesos que pueden estar ubicados en computadores diferentes

• Utiliza los protocolos TCP-UDP-IP

û PF_CCITT, PF_DECnet, PF_OSI, PF_X25 .....

ü Direcciones (Address Family): û AF_UNIX: formato UNIX

• Tiene el mismo formato de un fichero

û AF_INET: formato INET • Dirección IP, Puerto y Protocolo (TCP/UDP)


6

SITR: RedesSOCKETS


ü Tipos de Comunicación:û SOCK_STREAM: comunicación orientada a la conexión (usa TCP)

û SOCK_DGRAM: comunicación de tipo datagrama (usa UDP)û Otros tipos:

• SOCK_SEQPAQUET : comunicación secuencial similar al tipo STREAM pero garantizando que se mantienen los límites entre mensajes.

• SOCK_RDM : comunicación fiable sin conexión (similar al tipo DGRAM pero con control de errores)

• SOCK_RAW : privilegio de ROOT. Permite acceder a los protocolos de bajo nivel.

•4


7

SITR: RedesSOCKETS

Estructuras de Datos (1)

ü Estructuras de direcciones AF_INET#include <sys/socket.h>#include <netinet/in.h>

/* Estructura genérica de direcciones, válida para cualquier dominio (UNIX o INET). Las direcciones usadas deben ser forzadas a este tipo cuando se pasan como parámetro de una función. */

struct sockaddr {

sa_family_t sa_family; /* address family */

char sa_data[14]; /* up to 14 bytes of direct address */

};

/* Estructura de direcciones INET. */

struct sockaddr_in {

sa_family_t sin_family; /* AF_INET */

in_port_t sin_port; /* Puerto */

struct in_addr sin_addr; /* dirección IP */

char sin_zero[8];

};


8

SITR: RedesSOCKETS

/* el campo normalmente utilizado es s_addr definido como un entero largo */

struct in_addr {union {

struct { uchar_t s_b1, s_b2, s_b3, s_b4; } _S_un_b;struct { ushort_t s_w1, s_w2; } _S_un_w;

#if !defined(_XPG4_2) || defined(__EXTENSIONS__)uint32_t _S_addr;

#elsein_addr_t _S_addr;

#endif /* !defined(_XPG4_2) || defined(__EXTENSIONS__) */} _S_un;

/* should be used for all code */#define s_addr _S_un._S_addr

};

Estructuras de Datos (2)

ü Estructura para la dirección IP#include <netinet/in.h>

•5


9

SITR: RedesSOCKETS

Funciones Auxiliares (1)

ü Funciones para el manejo de direcciones INETû Cada máquina tiene una forma de representar la información numérica

por lo que se utilizan funciones de conversión a un formato estándar#include <arpa/inet.h>

/* convierte una cadena en formato W.X.Y.Z en una dirección IP de redin_addr_t inet_addr(const char *); /* convierte una dirección IP de red en una cadena en formato W.X.Y.Zchar *inet_ntoa(struct in_addr);

/*convierten puertos y direcciones de hosts a red y viceversa */

in_addr_t htonl(in_addr_t hostlong);

in_port_t htons(in_port_t hostshort);in_addr_t ntohl(in_addr_t netlong);in_port_t ntohs(in_port_t netshort);


10

SITR: RedesSOCKETS


ü Conversión de nombres simbólicos a direcciones IP#include <netdb.h>

#include <sys/socket.h>

struct hostent {char *h_name; /* official name of host */char **h_aliases; /* alias list */int h_addrtype; /* host address type */int h_length; /* length of address */char **h_addr_list; /* list of addresses from name server */

#define h_addr h_addr_list[0] /* address, for backward compatiblity*/};

/* obtiene la estructura de direcciones a partir del nombre simbólico DNS */struct hostent *gethostbyname(const char *);

/* Versión reentrante (Multithreading) */struct hostent *gethostbyname_r (const char *, struct hostent *,

char *, int, int *h_errnop);/* Obtiene la información de dirección/puerto de un socket existenteint getsockname(int socket, struct sockaddr * addr, size_t *lenght_addr);

•6


11

SITR: RedesSOCKETS


ü Valores de puertos y protocolo para los servicios estándar (/etc/services)#include <netdb.h>


struct servent {char *s_name; /* official service name */char **s_aliases; /* alias list */int s_port; /* port # */char *s_proto; /* protocol to use */

};

/* obtiene los datos de puerto y protocolo a partir de una cadena con el nombre del servicio */struct servent *getservbyname(const char *name, const char *proto);


12

SITR: RedesSOCKETS

Funciones Manejo de sockets (1)

#include <sys/types.h>


/* Crea un manejador para el socket */int socket(int domain, int type, int protocol);

domain: PF_INETtype: SOCK_STREAM, SOCK_DGRAMprotocol: 0 (Protocolo por omisión)Devuelve el manejador (<0 si es un error)

int close(int s); /* elimina el manejador del socket */

/* Nombra el socket (Asigna dirección y puerto ) *//* Nota: El socket cliente se nombra automáticamente */int bind(int s, const struct sockaddr * name, size_t namelen);

s: identificador del socketname: puntero a la estructura dirección/puerto (se debe hacer un cast desde la estructura sockaddr_innamelen : tamaño de la estructuradevuelve 0 si es correcto (-1 si se produce un error)

•7


13

SITR: RedesSOCKETS


ü Sockets orientados a al conexión:

Servidor:/* Especifica el tamaño de la caché de solicitudes */int listen(int s, int backlog);/* pone al servidor en espera de una conexión */int accept(int s, struct sockaddr *addr, size_t *addrlen);

s: identificador del socket de escuchaaddr:almacena los datos del clienteaddrlen : almacena el tamaño de la dirección del cliente

Si se establece una conexión devuelve un socket de diálogosi es incorrecto devuelve -1

Cliente:/* establece una conexión */int connect(int s, const struct sockaddr *name, size_t namelen);


14

SITR: RedesSOCKETS


ü Lectura y escritura en un socket

ssize_t sendto(int socket, const void *message,size_t length, int flags,const struct sockaddr *dest_addr, size_t dest_len);

/*solo en modo STREAM */ssize_t send(int socket, const void *buffer,

size_t length, int flags);ssize_t write(int fildes, const void *buf, size_t nbytes;

ssize_t recvfrom(int socket, void *message,size_t length, int flags,const struct sockaddr *dest_addr, size_t *dest_len);

/* solo en modo STREAM */ssize_t recv(int socket, void *buffer, size_t length,int flags);ssize_t read(int fildes, void *buf, size_t nbytes);

•8


15

SITR: RedesSOCKETS

Estructura de una Aplicación

ü Arquitectura Cliente-Servidorû Proceso Servidor: está continuamente escuchando el socket

• Un solo Thread: se atienden las peticiones secuencialmente

• Multithreading: se asigna un thread por cada solicitud

û Proceso Cliente: toma la iniciativa en la transmisión û Cliente y servidor tienen sus propias direcciones IP y puertos. û El puerto del servidor debe ser fijo, pero el puerto del cliente se asigna

dinámicamente

Proceso Cliente

Socket Cliente

Socket Servidor

Proceso Servidor

SOCK_DGRAM SOCK_STREAM

Proceso Cliente

Socket Cliente

Socket Diálogo

Proceso Servidor

Socket Escucha

1

/********************************************************************** Ejemplo de programación sobre sockets PF_INET de tipo Datagrama (UDP) Extremo Cliente (Emisor) ------> **********************************************************************/ #include <stdlib.h> #include <stdio.h> #include <sys/types.h> #include <errno.h> #include <unistd.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> const char *datos= "Este es el mensaje enviado desde el cliente SOCK_DGRAM"; int main(int argc, char *argv[]) { int socketCliente; // identificador de dispositivo para el socket struct sockaddr_in datosSocket; // dirección IP, tipo y puerto struct hostent *hp; // dirección IP a partir de nombre simbólico ssize_t res; // resultado de un sento()

if(argc!=3) { printf("Uso del programa: %s servidor puerto\n", argv[0]); exit(0); } /* 1ª etapa: Creamos un socket PF_INET de tipo SOCK_DGRAM (obtenemos un manejador) *********************************************************************** */ socketCliente = socket( PF_INET, SOCK_DGRAM, 0); if(socketCliente<0) { perror("Creando socket"); exit(-1); } /* 2ª etapa: Obtenemos la dirección IP y puerto del servidor a partir de los parámetros *********************************************************************** */ // convierte el nombre simbólico a una dirección IP hp=gethostbyname(argv[1]); if(hp == 0) { fprintf(stderr, "\n %s: host desconocido\n", argv[1]); exit(-2); } // copiamos la dirección IP en la estructura datosSocket memcpy( (char*) &datosSocket.sin_addr, (char*) hp->h_addr, hp->h_length); datosSocket.sin_family=AF_INET; // tipo de dirección // convierte el puerto a un número de red (htons) datosSocket.sin_port = htons(atoi(argv[2])); // muestra los datos del servidor en pantalla printf("Dir IP Svc: %s, Puerto Svc: %u\n", inet_ntoa(datosSocket.sin_addr), ntohs(datosSocket.sin_port)); /* 3ª etapa: Enviamos información al servidor. Opciones: ssize_t sendto(int socket, const void *message, size_t length, int flags, const struct sockaddr *dest_addr, size_t dest_len); *********************************************************************** */ res = sendto(socketCliente, datos, strlen(datos)+1, 0, (struct sockaddr *) &datosSocket, sizeof datosSocket); if(res<0) { perror("Escribiendo socket"); exit(-1); } /* 4ª etapa: Cerrar el socket ********************************************************************** */ close(socketCliente); exit(0); }

2

/* ********************************************************************* Ejemplo de programación sobre sockets PF_INET de tipo Datagrama (UDP) ------> Extremo Servidor (Receptor) **********************************************************************/ #include <stdlib.h> #include <stdio.h> #include <sys/types.h> #include <errno.h> #include <unistd.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> #define DIM 256 #define PUERTO (IPPORT_RESERVED+1) // selecciona el puerto del servidor int main(int argc, char *argv[]) { int socketServidor; // identificador de dispositivo para el socket struct sockaddr_in datosSocket; // dirección IP, tipo y puerto struct sockaddr_in datosSocketCliente; // datos del cliente ssize_t res; // resultado de un recvfrom() size_t longdir; int ires; char datos[DIM]; if(argc>1) { printf("Uso del programa: %s\n", argv[0]); exit(0); } /* 1ª etapa: Creamos un socket PF_INET de tipo SOCK_DGRAM (obtenemos un manejador) *********************************************************************** */ socketServidor = socket( PF_INET, SOCK_DGRAM, 0); if(socketServidor<0) { perror("Creando socket"); exit(-1); } /* 2ª etapa: Configuramos la estructura dirección: puerto 0 -> primero libre IPPORT_RESERVED+1 selección fija la dirección IP se toma la suya propia INADDR_ANY ya que es el servidor *********************************************************************** */ datosSocket.sin_family=AF_INET; // tipo de dirección // convierte el puerto a un número de red (htons) datosSocket.sin_port = htons(PUERTO); // convierte la dirección IP a un número de red (htonl) datosSocket.sin_addr.s_addr = htonl(INADDR_ANY); // continua à

3

/* Servidor UDP Continuación 3ª etapa: Nombramos el socket asignándole el puerto y dirección *********************************************************************** */ ires = bind(socketServidor, (struct sockaddr *) &datosSocket, sizeof datosSocket); if(ires<0) { perror("Nombrando el socket"); exit(-2); } // Pedimos los datos del puerto asignado ires = getsockname(socketServidor, (struct sockaddr *) &datosSocket, &longdir);

if(ires<0) { perror("Leyendo información del socket"); exit(-2); } // muestra los datos del servidor printf("Dir IP Svc: %s, Puerto Svc: %u\n", inet_ntoa(datosSocket.sin_addr), ntohs(datosSocket.sin_port)); /* 4ª etapa: Recibimos información del cliente. Opciones: ssize_t recvfrom(int socket, void *message, size_t length, int flags, const struct sockaddr *dest_addr, size_t *dest_len); *********************************************************************** */ longdir = sizeof datosSocketCliente; res = recvfrom(socketServidor, datos, DIM, 0, (struct sockaddr *) &datosSocketCliente, &longdir); if(res<0) { perror("Leyendo socket"); exit(-3); } // muestra lo que ha leido printf("Leido del socket: %d datos -> %s\n", res, datos); // muestra los datos del cliente printf("Dir IP Clnt: %s, Puerto Clnt: %u\n", inet_ntoa(datosSocketCliente.sin_addr), ntohs(datosSocketCliente.sin_port)); /* 5ª etapa: Cerrar el socket ********************************************************************** */ close(socketServidor); exit(0); }

4

/********************************************************************** Ejemplo de programación sobre sockets PF_INET de tipo STREAM (TCP) Extremo Cliente (Emisor) ------> **********************************************************************/ #include <stdlib.h> #include <stdio.h> #include <sys/types.h> #include <errno.h> #include <unistd.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> const char *datos= "Este es el mensaje enviado desde el cliente SOCK_STREAM"; int main(int argc, char *argv[]) { int socketCliente; // identificador de dispositivo para el socket struct sockaddr_in datosSocket; // dirección IP, tipo y puerto struct hostent *hp; // dirección IP a partir de nombre simbólico ssize_t res; // resultado de un sento() int ires; if(argc<3) { printf("Uso del programa: %s servidor puerto", argv[0]); exit(0); } /* 1ª etapa: Creamos un socket PF_INET de tipo SOCK_STREAM (obtenemos un manejador) *********************************************************************** */ socketCliente = socket( PF_INET, SOCK_STREAM, 0); if(socketCliente<0) { perror("Creando socket2"); exit(-1); } /* 2ª etapa: Obtenemos la dirección IP y puerto del servidor a partir de los parámetros *********************************************************************** */ // convierte el nombre simbólico a una dirección IP hp=gethostbyname(argv[1]); if(hp == 0) { fprintf(stderr, "\n %s: host desconocido\n", argv[1]); exit(-2); } // copiamos la dirección IP en la estructura datosSocket memcpy( (char*) &datosSocket.sin_addr, (char*) hp->h_addr, hp->h_length); datosSocket.sin_family=AF_INET; // tipo de dirección // convierte el puerto a un número de red (htons) datosSocket.sin_port = htons(atoi(argv[2])); // muestra los datos del servidor en pantalla printf("Dir IP Svc: %s, Puerto Svc: %u\n", inet_ntoa(datosSocket.sin_addr), ntohs(datosSocket.sin_port)); /* Continua ------------------à */

5

/* Cliente TCP Continuación

3ª etapa: Establecemos la conexión *********************************************************************** */ ires = connect(socketCliente, (struct sockaddr *) &datosSocket, sizeof datosSocket); if(ires == -1) { perror("Conexión no aceptada"); exit(-3); } /* 4ª etapa: Enviamos información al servidor. Opciones: ssize_t write(int fildes, const void *buf, size_t nbytes) ssize_t send(int socket, const void *buffer, size_t length, int flags); ssize_t sendto(int socket, const void *message, size_t length, int flags, const struct sockaddr *dest_addr, size_t dest_len); *********************************************************************** */ res = send(socketCliente, datos, strlen(datos)+1, 0); if(res<0) { perror("Escribiendo socket"); exit(-4); } /* 5ª etapa: Cerrar el socket ********************************************************************** */ close(socketCliente); exit(0); }

6

/* ********************************************************************* Ejemplo de programación sobre sockets PF_INET de tipo STREAM (TCP) ------> Extremo Servidor (Receptor) **********************************************************************/ #include <stdlib.h> #include <stdio.h> #include <sys/types.h> #include <errno.h> #include <unistd.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> #define DIM 256 #define PUERTO (IPPORT_RESERVED+1) // selecciona el puerto del servidor int main(int argc, char *argv[]) { int socketServidor; // identificador de dispositivo para el socket int socketMensaje; struct sockaddr_in datosSocket; // dirección IP, tipo y puerto struct sockaddr_in datosSocketCliente; // datos del cliente ssize_t res; // resultado de un recvfrom() size_t longdir; int ires; int cont; // contador de conexiones char datos[DIM];

if(argc>1) { printf("Uso del programa: %s\n", argv[0]); exit(0); } /* 1ª etapa: Creamos un socket PF_INET de tipo SOCK_STREAM (obtenemos un manejador) *********************************************************************** */ socketServidor = socket( PF_INET, SOCK_STREAM, 0); if(socketServidor<0) { perror("Creando socket"); exit(-1); } /* 2ª etapa: Configuramos la estructura dirección: puerto 0 -> primero libre IPPORT_RESERVED+1 selección fija la dirección IP se toma la suya propia INADDR_ANY ya que es el servidor *********************************************************************** */ datosSocket.sin_family=AF_INET; // tipo de dirección // convierte el puerto a un número de red (htons) datosSocket.sin_port = htons(PUERTO); // convierte la dirección IP a un número de red (htonl) datosSocket.sin_addr.s_addr = htonl(INADDR_ANY); /* 3ª etapa: Nombramos el socket asignándole el puerto y dirección *********************************************************************** */ ires = bind(socketServidor, (struct sockaddr *) &datosSocket, sizeof datosSocket); if(ires<0) { perror("Nombrando el socket"); exit(-2); } // Pedimos los datos del puerto asignado ires = getsockname(socketServidor, (struct sockaddr *) &datosSocket, &longdir); if(ires<0) { perror("Leyendo información del socket"); exit(-2); }

// continua -à

7

// Servidor TCP Continuación // muestra los datos del servidor

printf("Dir IP Svc: %s, Puerto Svc: %u\n", inet_ntoa(datosSocket.sin_addr), ntohs(datosSocket.sin_port));

/* 4ª etapa: Poner en escucha el servidor con una cola de 5 mensajes cuando aperec euna conexión aparece un nuevo socket *********************************************************************** */ listen(socketServidor, 5); // aceptar 5 conexiones for(cont=0; cont<4; cont++) { printf("Esperando datos....\n"); longdir = sizeof datosSocketCliente; socketMensaje = accept(socketServidor, (struct sockaddr *) &datosSocketCliente, &longdir); // se ha creado un nuevo socket para la conexión en curso if(socketMensaje == -1) { perror("Conexión no aceptada"); exit(-3); } /* 5ª etapa: Recibimos información del cliente. Opciones: ssize_t read(int fildes, void *buf, size_t nbytes) ssize_t recv(int socket, void *buffer, size_t length, int flags); ssize_t recvfrom(int socket, void *message, size_t length, int flags, const struct sockaddr *dest_addr, size_t *dest_len); *********************************************************************** */ res = recv(socketMensaje, datos, DIM, 0); if(res<0) { perror("Leyendo socket"); exit(-3); } // muestra lo que ha leido printf("Conexión %d\n", cont+1); printf("Leido del socket: %d datos -> %s\n", res, datos); printf("Eliminando la conexión\n"); close(socketMensaje); // cierra la conexión } /* 5ª etapa: Cerrar el socket ********************************************************************** */ close(socketServidor); exit(0); }

Apuntes SITR

Documents

Transcript of Apuntes SITR