Hola, tenemos una duda, es posible en monitores definir un arreglo de conditions?
Vimos que en la solución de los Filósofos que cenan, en las diapositivas definen un array de monitores para los tenedores. Nosotros hicimos un array de conditions y un único monitor con los procedure's entrar, salir, tomar y dejar definiendo un array de conditions del estilo:
tenedores : Array[1..5] of Conditions.
Gracias.
Hola,
Es posible hacer un arreglo de conditions, es una variable como cualquier otra y por tanto se pueden hacer arreglos de ellas.
Para el problema de los filósofos no es una buena solución porque el monitor garantiza la mutoexclusión. Eso provoca que al hacerlo con un monitor en el caso de que hubiese más de un tenedor libre dos filósofos distintos no podrían tomar a la vez dos tenedores distintos lo cuál le quita concurrencia al problema (o cuando están saliendo/entrando filósofos). En definitiva no estaría mal mal pero es peor solución que la de las diapositivas
Saludos!
En respuesta a Manuel Freire
Re: [Monitores] Array of Conditions?
Entiendo lo que decís, pero al dejar entrar solamente a 4 filósofos (como plantean en las diapositivas) no estarías perdiendo concurrencia también?
Digo porque, por ejemplo, para no perder concurrencia se podría dejar entrar a los 5 filósofos a la vez; pero solo permitís que cada uno agarre de a 2 cubiertos.
En respuesta a Hugo Sebastian Rodriguez Reyes
Re: [Monitores] Array of Conditions?
de Manuel Freire -
Si, pero es una pérdida de concurrencia necesaria al igual que agarrar los cubiertos de a 2. Serían dos soluciones válidas dependiendo de cómo hagas el código y la realidad del problema (que eso sea escalable y no termine serializándolo). Cualquiera de las opciones para evitar o prevenir el deadlock quita concurrencia para asegurar el funcionamiento.
La cosa es que en el caso que proponían arriba la solución si bien funcionaba no era buena, pedir de a dos, pedir en orden o dejar entrar solo a n-1 son todas equivalentes
En respuesta a Manuel Freire
Re: [Monitores] Array of Conditions?
Entiendo.
Una última duda:
A qué te referís con “serializándolo”?
Con escalable imagino que querés decir que puedas extenderlo a N filósofos, no?
En respuesta a Hugo Sebastian Rodriguez Reyes
Re: [Monitores] Array of Conditions?
de Manuel Freire -
Que se ejecuten en serie es que vayan uno atrás de otro con todos los demás procesos bloqueados esperando un recurso, en definitiva sin concurrencia. El caso extremo sería poner un mutex que se pide al principio del proceso y se devuelve al final, en definitiva si bien estás programando concurrentemente estás forzando a que se ejecuten uno atrás del otro en serie.
Serializándolo lo estaba usando como aproximación a eso: si tenés 500 procesos y de esos 495 están bloqueados esperando en el mismo semáforo/entrycall/etc es probable que estés haciendo algo mal, puede llegar a pasar si hay un recurso único y todos lo necesitan pero generalmente en los ejercicios que se plantean en el curso es una mala resolución.
Pensá en el ejemplo hablado más arriba que hay un monitor que maneja las quinientos tenedores y sin importar cómo lo guarda adentro qué tenedores están ocupados y cuáles no. Vos no vas a quedar nunca en deadlock ya que eso te garantiza el monitor que si no tiene para darle los dos tenedores lo duerme pero lo que vas a tener es que la gran mayoría de los procesos van a estar bloqueados esperando por el monitor. Porque todos van a necesitar usarlo para entrar, salir y encima pedir tenedores que en la gran mayoría de los casos son de gente que ni siquiera está cerca en esa mensa gigante. Eso va a terminar en que solo pocos procesos estén ejecutando a la vez no porque no haya recursos disponibles si no porque están generaste vos un "recurso" más escaso que los que había para manejar y dejaste un cuello de botella en otro lado. En ese caso la solución estaría mal.
Como todo depende de tu realidad, capaz que en cinco es equivalente pero en quinientos vas a tener que buscar otra porque en deifnitiva si bien funciona (no hay deadlock y eventualmente todos van a comer) no es ni de cerca eficiente. A eso me refiero con lo de escalable: capaz que para tu realidad es correcta y una solución válida pero no es escalable porque por más que funciona empieza a generar muy poco uso de CPU que en definitva es lo que se pretende maximizar con la multiprogramación.
Disculpá la biblia pero quería que quede claro
Saludos!