CANALES SINCRONICOS Y ASINCRONICOS

CANALES SINCRONICOS Y ASINCRONICOS

Los protocolos de transferencia de información en canales de microprocesadores, se pueden
clasificar en tres grupos:

1. Sincrónicos: transferencias sincronizadas, una transferencia por período de reloj.
2. Asincrónicos: transferencias sin reloj de sincronismo.
3. Semisincrónicos: transferencias sincronizadas, una transferencia por uno o mßs
períodos de reloj.

Un microprocesador posee un canal de datos, uno de direcciones y uno de control. Este
último es el encargado de manejar el sincronismo. Para ello dispone de líneas a tal efecto,
llamadas de sincronismo o de "handshake". La función de estas líneas es la de indicar el
comienzo y el fin de una transferencia de datos o de información. La complejidad de estas
líneas depende del tipo de máquina.


1. Canales Sincrónicos

Los canales sincrónicos son los más fáciles de implementar ya que la única línea de control
es un reloj. El flanco ascendente del reloj indica el comienzo de la transferencia y el
descendente el fin de la misma. En este tipo de canales, las transferencias son controladas
por el reloj maestro. La principal ventaja de estos es que además de ser los más simples de
los tres protocolos, también conducen a las transacciones más rápidas, siempre y cuando la
respuesta de los dispositivos sean suficientemente rápidas para operar a la velocidad
impuesta por el reloj.

Un ejemplo de un microprocesador con estas características de transferencia es el 6800, tal

2. Canales Asincrónicos

El problema más importante de los buses sincrónicos se presenta cuando el procesador
debe manejar dispositivos de distintas velocidades de operación, ya que el procesador
debería funcionar a la velocidad del dispositivo más lento (en algunos procesadores como
el 6800, es posible "estirar" un poco el ancho del pulso del reloj).

Lo ideal sería contar con transacciones rápidas para los dispositivos rápidos y lentas para
los dispositivos lentos o distantes en el bus.

Las señales de control, tal como se muestra en la Fig. C2, se denominan MASTER y
SLAVE. Este protocolo requiere un cambio nivel (flanco) para alternar entre las señales de
control. Esto garantiza que la información en el canal de datos y direcciones se transmita
sin conflictos y sin pérdida o duplicación en el bus. Un ejemplo de este tipo de canal es el
del microprocesador LSI-11 de Digital.

La principal desventaja de este tipo de canal es el retardo de propagación, que limitan el
ancho de banda del canal.


3. Canal Semisincrónico

Una solución alternativa intermedia entre velocidad de operación y compatibilidad entre
dispositivos de distintas velocidades sería el canal semisincrónico. En este se distinguen
dos señales de control: una es el reloj o una señal proporcional al reloj del microprocesador
(señales RD o WR), que son enviadas por el master y la otra es la señal WAIT que es
enviada por el slave, la cual controla la velocidad de transferencia "estirando" los accesos a los dispositivos.

La se±al WAIT se la denomina también XACK ("transfer acknowledge"). El slave
direccionado debe proveer al maestro con una señal de reconocimiento en respuesta a un
control de la transferencia (comando read o write). Esta línea la emite el slave para
indicarle al master que la operación del comando de lectura o escritura fue completada y
que la información sobre el canal de datos fue aceptada. Por lo tanto, la línea XACK le
permite a la CPU completar el ciclo corriente de canal. Si la línea XACK no es retornada a
la CPU, ésta entra en un estado "WAIT" hasta que la misma sea devuelta. En estos
sistemas, para evitar los tiempos indefinidos de estados "WAIT", debido a un error de
direccionamiento, se debe preveer funciones de "time-out" para finalizar el ciclo de canal,
después de un determinado período de tiempo.

En el caso en el cual los dispositivos sean lo suficientemente rápidos, el canal se comporta
como sincrónico; en cambio si el slave no puede responder en el tiempo de acceso de la
CPU, debe generar un tiempo de espera, comportándose en este caso como asincrónico. Un
ejemplo de un microprocesador con estas características de transferencia es el 8085, tal
La ventaja de estos tipos de canales es que pueden tener la velocidad de los sincrónicos y la
versatilidad de los asincrónicos. Sin embargo la desventaja sería la máxima longitud del
canal, ya que la señal wait debe ser establecida en un período de tiempo fijo.


Proceso de Sincronismo

Cuando se desea transferir información de un dispositivo a otro (microprocesador -
memoria o entrada/salida), se deben considerar una serie de operaciones:

- Presentar dirección de memoria.
- Proceso de sincronismo.
- Transferencia de información.

En el proceso de sincronismo actúan ciertas líneas del canal de control del
microprocesador. Por proceso de sincronismo se entiende el hecho de determinar el
momento (tiempo) exacto cuando se produce la transferencia de información y de
establecer la dirección de la transferencia de la información (lectura o escritura). Por lo
tanto es necesario diferenciar 3 estados:

- Lectura.
- Escritura.
- No acceso al canal (canal ocioso).

Esto nos indica que es por lo menos necesario contar con 2 líneas del canal de control para
poder diferenciar dichos estados. Existen históricamente 2 escuelas bién diferenciadas para
la implementación: La primera sigue las técnicas de los microprocesadores de Intel
(8080/8085), que consiste en emplear dos líneas de sincronismo mutuamente excluídas:
señal /WR y señal /RD, las cuales indican el instante (temporizado) y la operación de
escritura o de lectura respectivamente. La segunda sigue las técnicas de los
microprocesadores de Motorola (6800), que consiste en emplear una línea lógica de
lectura-escritura (R/W), que indica la dirección de los datos y otra de sincronismo (φ2),
indicando el instante de la transferencia.

Muy amenudo surgen problemas de sincronización cuando se desean conectar dispositivos
periféricos diseñados para un tipo de microprocesador, a otro microprocesador. Por
ejemplo si se desea conectar un dispositivo compatible con el microprocesador 6800 a un
microrpocesador 8085, surgen problemas en los ciclos de escritura. La línea /WR del mp
tiene la polaridad correcta con respecto a la línea R/W del dispositivo, sin embargo como la
primera define además el sincronismo de escritura, no podría conectarse directamente a la
segunda, debido a que estos dispositivos necesitan un tiempo de establecimiento ("set-up")
Para lograr la conexión deseada sería necesario generar la línea E como la función lógica Nand de las líneas /RD y /WR y además generar
un estado tWAIT desactivando la línea READY del mp 8085.



Operaciones sincrónicas y asincrónicas

Describe implementaciones asincrónicas locales e invocaciones, así como el uso sincrónico de intercambios de mensajes asincrónicos.

Muchas aplicaciones llaman de forma asincrónica a los métodos porque permite que la aplicación siga realizando trabajo útil mientras se ejecuta la llamada al método. Los servicios y clientes Windows Communication Foundation (WCF) pueden participar en llamadas de operación asincrónicas en dos niveles distintos de la aplicación, que proporcionan a las aplicaciones WCF aún más flexibilidad para maximizar el rendimiento buscando el equilibrio con la interactividad.

Tipos de operaciones asincrónicas

Todos los contratos de servicio en WCF, sin tener en cuenta los tipos de parámetros y valores de retorno, usan atributos WCF para especificar un determinado modelo de intercambio de mensajes entre el cliente y el servicio. WCF enruta automáticamente mensajes de entrada y salida a la operación de servicio adecuada o al código de cliente ejecutor.

El cliente posee solo el contrato de servicio, que especifica el modelo de intercambio de mensajes para una operación determinada. Los clientes pueden ofrecer cualquier modelo de programación que elijan al programador, siempre y cuando se observe el modelo de intercambio de mensajes subyacente. Así, también, los servicios pueden implementar operaciones de cualquier manera, siempre que se observe el modelo del mensaje especificado.

La independencia del contrato de servicio del servicio o de la implementación del cliente habilita los formularios siguientes de ejecución asincrónica en aplicaciones WCF:

• Los clientes pueden invocar operaciones de solicitud/respuesta asincrónicamente mediante un intercambio de mensajes sincrónico.
• Los servicios pueden implementar una operación de solicitud/respuesta asincrónicamente mediante un intercambio de mensajes sincrónico.
• Los intercambios de mensajes pueden ser unidireccionales, sin tener en cuenta la implementación del cliente o servicio.


Escenarios asincrónicos sugeridos

Use un enfoque asincrónico en una implementación de operación de servicio si la implementación del servicio de la operación realiza una llamada en bloque, como al realizar operaciones de E/S. En una implementación de operación asincrónica, intente llamar a métodos y operaciones asincrónicos para extender la ruta de acceso de la llamada asincrónica al máximo. Por ejemplo, llame a una BeginOperationTwo() desde BeginOperationOne().

• Use un enfoque asincrónico en una aplicación de cliente o que realiza la llamada en los casos siguientes:
• Si invoca operaciones desde una aplicación de nivel intermedio. (Para obtener más información acerca de estos escenarios, consulte Aplicaciones cliente de nivel intermedio.)
• Si invoca operaciones desde una página ASP.NET, use páginas asincrónicas.
• Si invoca operaciones desde cualquier aplicación de proceso simple, como Windows Forms o Windows Presentation Foundation (WPF). Si utiliza el modelo de llamada asincrónica basado en evento, el evento resultante se produce en el proceso de interfaz de usuario, agregando capacidad de respuesta a la aplicación sin que sea necesario controlar procesos múltiples.
• En general, si puede elegir entre una llamada sincrónica y una asincrónica, elija la asincrónica.
Llamadas asincrónicas del cliente
Una aplicación de cliente WCF puede utilizar uno o dos modelos de llamada asincrónica, ambos descritos en Asynchronous Programming Design Patterns:
• Operaciones asincrónicas que utilizan eventos.
• Operaciones asincrónicas que utilizan objetos System.IAsyncResult.
El primer enfoque, el modelo asincrónico basado en eventos, se recomienda para llamar a aplicaciones, ya que solo requiere agregar un controlador de eventos para recibir una notificación de la respuesta, y el evento resultante que se genera automáticamente en el proceso de la interfaz de usuario. Para aplicar este enfoque, especifique las opciones de comando /async y /tcv:Version35 con la Herramienta de utilidad de metadatos de ServiceModel (Svcutil.exe), como en el ejemplo siguiente.


Copiar

svcutil http://localhost:8000/servicemodelsamples/service/mex /async /tcv:Version35
Una vez hecho esto, Svcutil.exe genera una clase de cliente WCF con la infraestructura de cliente que permite a la aplicación de llamada implementar y asignar un controlador de eventos para recibir la respuesta y realizar la acción apropiada. Para obtener un ejemplo completo, consulte Cómo llamar a operaciones del servicio WCF de forma asincrónica.
El modelo asincrónico basado en eventos, sin embargo, solo está disponible en Versión 3.5 de .NET Framework. Además, no está permitido ni en .NET Framework 3,5 cuando se crea un canal de cliente WCF mediante System.ServiceModel.ChannelFactory. Con objetos de canal de cliente WCF, debe utilizar objetos System.IAsyncResult para invocar sus operaciones asincrónicamente. Para aplicar este enfoque, especifique la opción de comando /async con la Herramienta de utilidad de metadatos de ServiceModel (Svcutil.exe), como en el ejemplo siguiente.

Copiar

svcutil http://localhost:8000/servicemodelsamples/service/mex /async
Esto genera un contrato de servicio en el cual cada operación se modela como un método con la propiedad AsyncPattern establecida en true y un método correspondiente. Para obtener un ejemplo completo mediante ChannelFactory, vea Cómo llamar a operaciones de manera asincrónica mediante un generador de canales.

En cualquier caso, las aplicaciones pueden invocar una operación asincrónicamente aun cuando se implementa el servicio sincrónicamente, del mismo modo que una aplicación puede usar el mismo modelo para invocar de forma asincrónica un método sincrónico local. Cómo se implementa la operación no es significativo para el cliente; cuando llega el mensaje de respuesta, su contenido se envía al método de extremo asincrónico del cliente y el cliente recupera la información.


Implementaciones de operación asincrónica

Igualmente, una operación de servicio se puede implementar asincrónicamente mediante el modelo de programación asincrónico .NET Framework y marcando el método con la propiedad AsyncPattern establecida en true. En este caso, la operación asincrónica se expone en metadatos de la misma manera que una operación síncrona: se expone como una operación única con un mensaje de solicitud y un mensaje de respuesta correlativo. Los modelos de programación de cliente tienen entonces una opción. Pueden representar este modelo como una operación síncrona o como una asincrónica, siempre que se origine un intercambio de mensajes solicitud-respuesta cuando se invoque el servicio.

Para ver un ejemplo, consulte Cómo: Implementar una operación de servicios asincrónica.
Para definir una operación de contrato X que se ejecuta asincrónicamente sin tener en cuenta cómo se llama en la aplicación cliente:

• Defina dos métodos mediante el modelo BeginOperation y EndOperation.
• El método BeginOperation incluye parámetros in y ref para la operación y devuelve un tipo IAsyncResult.
• El método EndOperation incluye un parámetro IAsyncResult así como los parámetros ref y out y devuelve el tipo de valor devuelto de las operaciones.
Por ejemplo, vea el método siguiente.
VB
C#
C++
F#
JScript
Copiar
Este idioma no es compatible o no hay ningún ejemplo de código disponible.
VB
C#
C++
F#
JScript
Copiar
Function DoWork(ByVal data As String, ByRef inout As String, _
out outonly As out) As Integer
Para crear una operación asincrónica, los dos métodos serían:
VB
C#
C++
F#
JScript
Copiar
Este idioma no es compatible o no hay ningún ejemplo de código disponible.
VB
C#
C++
F#
JScript
Copiar
_
Function BeginDoWork(ByVal data As String, _
ByRef inout As String, _
ByVal callback As AsyncCallback, _
ByVal state As Object) _
As IAsyncResult

Function EndDoWork(ByRef inout As String, _
ByRef outonly As String, _
ByVal result As IAsyncResult) _
As Integer

Nota:

El atributo OperationContractAttribute se aplica solamente a los métodos de BeginDoWork. El contrato resultante tiene una operación WSDL denominada DoWork.


Modelos de intercambio de mensajes unidireccional

También puede crear un modelo de intercambio de mensajes asincrónico en el que las operaciones unidireccionales (las operaciones para las que System.ServiceModel.OperationContractAttribute.IsOneWay es true no tienen ninguna respuesta puesta en correlación) se pueden enviar en cualquier dirección por el cliente o por el servicio, independientemente del otro lado. (Esto utiliza el modelo de intercambio de mensajes dúplex con mensajes unidireccionales.) En este caso, el contrato de servicio especifica un intercambio de mensajes unidireccional que cada parte puede implementar como llamadas asincrónicas o implementaciones, o no, según corresponda. Por lo general, cuando el contrato es un intercambio de mensajes unidireccionales, las implementaciones pueden ser muchas veces sincrónicas porque una vez se envía un mensaje, la aplicación no espera a una respuesta y puede continuar haciendo otro trabajo.


Clientes asincrónicos y contratos de mensajes basados en eventos

Las directrices de diseño del modelo asincrónico basado en eventos afirman que si se devuelve más de un valor, uno de los valores se devuelve como propiedad Result y los demás se devuelven como propiedades del objeto EventArgs. De esto resulta que si un cliente importa metadatos mediante opciones de comando asincrónicas basadas en eventos y la operación devuelve más de un valor, el objeto EventArgs predeterminado devuelve un valor como propiedad Result y el resto son propiedades del objeto EventArgs.
Si desea recibir el objeto del mensaje como propiedad Result y que los valores devueltos sean propiedades de ese objeto, use la opción de comando /messageContract. Esto genera una firma que devuelve el mensaje de respuesta como la propiedad Result del objeto EventArgs. Todos los valores de devolución internos se convierten, pues, en propiedades del objeto de mensaje de respuesta.