Diseñar una asignación para la programación multiproceso

Question

Este semestre soy un TA de un curso de SO. Así que me pidieron que diseñara una asignación de programación multiproceso para estudiantes universitarios de CS con habilidades limitadas de programación en C

Esto no debería ser una asignación grande porque solo toma el 5% de la calificación final. Y esto debería ser algo nuevo para que los estudiantes no puedan simplemente descargar un código de Internet.

Esto es lo que estoy pensando, un simple servidor de Message Queue.

Vamos a proporcionar un estudiante Sever MQ muy ficticia que tiene un solo hilo y acepta sólo 2 conexiones de cliente, un lector y un escritor. El escritor envía periódicamente un mensaje a la cola, es decir, el servidor, y el lector lee un mensaje de la cola, es decir, el servidor envía el mensaje al lector. También proporcionaremos al lector y al escritor .

Luego pedimos a los estudiantes que modifiquen el servidor para aceptar múltiples lectores y escritores al mismo tiempo. Y también le pediremos la seguridad del hilo . En otras palabras, un mensaje solo debe enviarse un lector, y no se pierde ningún mensaje en la cola, que requiere el uso de mutex.

Siento que podría ser demasiado simple, pero no se me ocurrió nada más en este momento. Si estuvieras en mi posición, ¿qué tarea me asignarás?

Answer 1

¿Estás usando Unix? No es que importe, también puede usar Windows para esto.

Simplemente, crea una tubería con nombre.

Luego crea 4 hilos.

1 hilo de control, 1 hilo de consumidor (lector) y 2 hilos de productor (autor).

Los productores simplemente envían una cadena a la tubería, y el consumidor toma la cadena, la parte superior o algo así y la imprime.

El hilo de control se utiliza para iniciar y detener los otros 3 hilos. Toma comandos simples: startProducer1, startProducer2, startConsumer, stop commands y un comando de apagado.

Esto muestra los diferentes hilos trabajando por su cuenta, pero al mismo tiempo siendo controlados por el maestro (saber cuándo apagarse, etc.).

Puntos de bonificación si puede envolver esto es una simple GUI, o incluso una pantalla de video Ncurses simple para que la pantalla de control siempre tenga visibilidad para aceptar los comandos y mostrar los resultados.

Puede mostrar si inicia 1 productor pero no los consumidores, cómo se bloqueará el hilo. Lo mismo con ambos productores, o cómo el consumidor bloquea sin productores.

Al usar la tubería, no tiene que depender de ese programa externo (y de todos los detalles para configurarlo, depurarlo, configurarlo y soportarlo).

Tanto Unix como Windows tienen canalizaciones con nombre (pero las llamadas al sistema creo que son diferentes, pero la portabilidad POSIX puede funcionar aquí ...).

Answer 2

puede tener Connection Pool Manager en su etapa primitiva que solo crea un grupo de conexión y es confiablemente capaz de usar y reutilizar un objeto de conexión.

En segundo lugar, puede tener un httpclient que puede realizar múltiples solicitudes GET solamente (ya que otras lo harán demasiado complejo), y debería poder verificar todas las respuestas correspondientes a cada solicitud (también puede hacerlo para cancelar el solicitud).

En tercer lugar, lo más simple es escribir un socket de servidor simple que pueda aceptar cada solicitud diferente y asignarla a un nuevo hilo de servidor, obtener la solicitud y devolver la respuesta.

eso es lo que se me ocurre fuera ..

Answer 3

La ventaja de los problemas clásicos como Dining Philosphers es que estancamiento y el hambre son fáciles de demostrar sin entrar profundamente en los detalles de implementación.

Si realmente necesita algo original, intente elegir un proyecto en el que sea fácil prever dificultades de simultaneidad. De esta manera es probable que los estudiantes se topen con ellos y saquen más provecho de la tarea. De lo contrario, reformular uno de los problemas clásicos por lo que es lo suficientemente diferente de las soluciones de Internet existentes, pero sigue siendo el mismo en esencia.

Answer 4

Me sentiría tentado de pedirles a los estudiantes que proporcionen una máquina de estado roscada para acceder a secciones críticas, por ejemplo, a un brazo robótico.

p. Ej. el hilo del brazo del robot contendría métodos públicos como "MoveArm (doble posición)" y "StopArm()", etc. todos ellos enviarían señales a la cola de señales del brazo del robot. El hilo del brazo del robot controlaría la cola y desconectaría las señales de una en una y actuaría en consecuencia, dejando otras solicitudes en cola para la siguiente secuencia de transiciones de estado. ¿Esto tiene sentido?

Esto demuestra cómo serializar el acceso no solo a las secciones críticas, sino a la secuencia crítica de acciones.

E.g. MoveArm llamado a partir de hilos 1 (por ejemplo, interfaz de usuario) se registró en la cola de la señal de los brazos de robot, y una vez que el hilo brazo robot detecta la señal en su propio hilo, se movería a través de los siguientes estados de ReadyState:

1. StartingToMoveArmState
2. MovingArmState (aquí podemos escuchar señales de StopArm (por ejemplo, si tenemos que de parada de emergencia etc.)
3. ReadyState (una vez mover completa).

de rosca 2 podría mientras que el hilo brazo robot está procesando 1 solicitud de mover el brazo, llame a StopArm() - y esto se manejaría en MovingArmState. Además, el hilo 2 podría pedirle al brazo que se mueva a otro lugar, pero el hilo del brazo del robot no lo repararía hasta que estuviera nuevamente en ReadyState. Es decir. ReadyState solo asignará la siguiente señal para moverse.

Por lo tanto, la cola de señal debe ser segura para hilos y bloqueada siempre que los hilos 1 o 2 le agreguen una señal. Además, la cola de señales necesita configurar el hilo del brazo del robot para desbloquear, de modo que pueda inspeccionar esta señal y actuar en consecuencia (utilizando, por ejemplo, un evento de reinicio manual).

¡Espero que esto pueda ser útil!