Sistemas operativos modernos

control al invocador, antes de que se envíe el mensaje. La ventaja de este esquema es que el proceso transmisor puede seguir computando en paralelo con la transmisión del mensaje, en lu­ gar de que la CPU esté inactiva (suponiendo que ningiín otro proceso esté listo). La decisión entre usar primitivas bloqueadoras y no bloqueadoras normalmente la toman los diseñadores del sistema (es decir, o está disponible una primitiva, o está disponible la otra), aunque en unos cuantos sistemas se cuenta con ambas y los usuarios pueden escoger su favorita. Sin embargo, la ventaja en cuanto a desempeño que ofrecen las primitivas no bloqueado- ras conlleva una desventaja grave: el transmisor no podrá modificar el búfer de mensaje mien­ tras no se envíe el mensaje. Las consecuencias de que el proceso sobrescriba el mensaje durante la transmisión serían tan horribles que no cabe imaginarlas. Peor aún, el proceso trans­ misor no tiene idea de si ya terminó la transmisión o no, así que nunca sabrá cuándo puede vol­ ver a usar el búfer sin peligro. Podría evitar volver a usar el búfer alguna vez. Hay tres posibles salidas de este dilema. La primera solución es pedir al kemel que copie el mensaje en un búfer interno y luego permita al proceso continuar, como se muestra en la fi­ gura 8-20b. Desde el punto de vista del transmisor, este esquema es lo mismo que una llamada bloqueadora: tan pronto como recupera el control, está en libertad de reutilizar el búfer. Desde luego, todavía no se habrá enviado el mensaje, pero eso no es problema para el transmisor. La desventaja de este método es que todos los mensajes de salida tienen que copiarse del espacio de usuario al espacio de kemel. Si hay muchas interfaces de red, el mensaje de todos modos ten­ drá que copiarse después en un búfer de transmisión de hardware, así que el primer copiado es en efecto un desperdicio. El copiado adicional puede mermar en forma considerable el desem­ peño del sistema. La segunda solución consiste en interrumpir al transmisor al terminar de enviar el mensa­ je, para avisarle que ya puede disponer otra vez del búfer. No se requiere ningún copiado aquí, lo que ahorra tiempo, pero las interrupciones en el nivel de usuario hacen que la programación sea complicada, difícil y sujeta a condiciones de competencia, con lo cual la ejecución se vuel­ ve irreproducible y casi imposible de depurar. La tercera solución es hacer que el búfer sea de tipo “copiar al escribir”; es decir, marcar­ lo como de sólo lectura hasta que se haya enviado el mensaje. Si el búfer se reutiliza antes de enviar el mensaje, se hace una copia. El problema con esta solución es que, a menos que el búfer esté aislado en su propia página, las escrituras en variables cercanas también obligarán a hacer una copia. Además, se requiere administración adicional porque el acto de enviar un mensaje ahora afecta de modo implícito la situación de lectura/escritura de la página. Por últi­ mo, tarde o temprano volverá a escribirse la página, generando una copia que quizá ya no sea necesaria. Por tanto, las opciones en el lado del transmisor son: 1. Send bloqueador (la CPU está inactiva durante la transmisión del mensaje). 2. Send no bloqueador con copia (se desperdicia fiempo de CPU por el copiado adicional). 3. Send no bloqueador con interrupción (dificulta la programación). 4. Copiar al escribir (es probable que tarde o temprano se necesite un copiado adicional).