Primitivas send/receive

[llabrac]

Buenos días, me ha salido esta pregunta:

En la primitiva send-receive qué características tienen send y receive? [N/C]
Tema: 50


a) Send en bloqueante y Receive es no bloqueante.
b) Ambas son bloqueantes.
c) Ambas son no bloqueantes.
d) Send es no bloqueante y Receive es bloqueante.

Dan como buena la D.

¿No sería buena la A? Si la comunicación entre procesos es asíncrona entiendo que ninguna es bloqueante pero, en el caso de ser síncrona, el proceso que envía se queda esperando hasta que recibe la respuesta por lo tanto send le ha bloqueado. Debo tener un error de concepto.

Muchas gracias.

[Miguelinho]

Esto lo vi en la carrera, claro como tantos. No recuerdo muy bien, pero mi lógica es la siguiente: El proceso que envía ya ha hecho su parte del trabajo, ha realizado el envío y puede continuar. Sin embargo, el proceso que recibe posiblemente necesite esos datos para realizar su trabajo y tiene que esperar.

[Itinerante]

En el tema 50 de Astic lo explica tal cual en una frase.

Ahora mismo no lo tengo aquí delante, pero es en los Mecanismos de Comunicación.

Y sí, la buena es la D

[llabrac]

Sí, lo vi Itinerante, y supongo que la pregunta está sacada directamente del temario. Sin embargo, viéndolo ahora con más profundidad, creo que no se puede decir categóricamente si send o receive son bloqueantes o no hasta determinar previamente si la comunicación es síncrona o asíncrona. Incluso en el propio temario (el mío es de 2010) habla de "habitualmente":

"Paso de Mensajes. Primitivas send/receive."
Se basa en el paso de mensajes mediante las primitivas send-receive. Cada pareja send-receive transmite un mensaje entre cliente y servidor, por lo general de forma asíncrona. Habitualmente:

- Send es no bloqueante (el nodo que envía el mensaje y no espera la respuesta del receptor)
- Receive es bloqueante (el nodo que espera un mensaje no realiza ninguna acción hasta que le llega)

En cualquier caso, muchas gracias a los dos.

[IngenieroInformatico]

El que envía continúa y el que recibe tiene que esperar a recibir el envío, por tanto la buena es la D. Para bloquear el proceso que envía primero, sería necesario establecer un mecanismo rendez-vous en el que, después del envío, se llame a un recieve en espera a que se ejecute toda la sección crítica del segundo proceso y éste envíe un mensaje al primero, siempre después de haber recibido el send del primer proceso.

Saludos.

[IngenieroInformatico]

Sí, lo vi Itinerante, y supongo que la pregunta está sacada directamente del temario. Sin embargo, viéndolo ahora con más profundidad, creo que no se puede decir categóricamente si send o receive son bloqueantes o no hasta determinar previamente si la comunicación es síncrona o asíncrona. Incluso en el propio temario (el mío es de 2010) habla de "habitualmente":

"Paso de Mensajes. Primitivas send/receive."
Se basa en el paso de mensajes mediante las primitivas send-receive. Cada pareja send-receive transmite un mensaje entre cliente y servidor, por lo general de forma asíncrona. Habitualmente:

- Send es no bloqueante (el nodo que envía el mensaje y no espera la respuesta del receptor)
- Receive es bloqueante (el nodo que espera un mensaje no realiza ninguna acción hasta que le llega)

En cualquier caso, muchas gracias a los dos.

Cuando habla de "habitualmente" es porque es así por defecto, aunque entiendo que se podrá indicar, si mal no recuerdo, mediante una constante mapeada en la llamada, el comportamiento de la misma. Es algo así como la llamada "select", que es bloqueante por defecto aunque se puede configurar de muchas formas.

[llabrac]

En estas trasparencias de la facultad de la upm se indica que la recepción siempre es bloqueante y que el envío, depende de si la comunicación es síncrona o asíncrona (transparencia 6/32):

http://lml.ls.fi.upm.es/pc/transparenci ... dout_4.pdf

Para mí, es una pregunta impugnable puesto que la B es cierta en el caso de comunicación síncrona. En fin, lo importante es entenderlo para futuras preguntas