Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consultas Comanda #1928

Closed
nico-abram opened this issue Sep 25, 2020 · 4 comments
Closed

Consultas Comanda #1928

nico-abram opened this issue Sep 25, 2020 · 4 comments

Comments

@nico-abram
Copy link

nico-abram commented Sep 25, 2020

Buenas!

  1. plato_listo: comanda debe pasar a swap todas las paginas del pedido que vaya iterando mientras busca el nombre del plato? Esa lectura actualiza el timestamp de ultimo uso para el cache LRU? Cuando el plato llega a la cantidad total, y se itera a ver si estan todos los platos del pedido listos para cambiar el estado del pedido, se actualiza el timestmap de los platos?

  2. obtener_pedido: Que hace comanda si no encuentra el pedido? (Estoy devolviendo un estado extra "INVALIDO")

  3. obtener_pedido: Comanda actualiza el timestamp de todos los platos en el pedido?

  4. guardar_plato: Se puede hacer si el estado es PENDIENTE? (Osea, no confirmado)

  5. finalizar_pedido: Comanda debe verificar que el estado sea TERMINADO?

  6. Hay algun requerimiento en como resolvemos temas de concurrencia en comanda? O seria valido tener un gran mutex para todo que se lockie y deslockie cuando se maneja cada mensaje?

@iago64
Copy link
Contributor

iago64 commented Sep 25, 2020

Aloha! como va?
Las preguntas asi numeradas son una genialidad para contestar, mil gracias ☺️

1.- Nope, las cosas a swap bajan solo al momento de reemplazar, si no, queda en memoria principal y nada mas

2.- Fijate que en el paso 2 esta la aclaración de que En caso de no existir se deberá informar dicha situación, con lo cual esta perfecto el estado extra digamos.

3.- Si, pensá que técnicamente accediste a todos los pedidos para saber las cantidades 😉

4.- Buena pregunta, la idea es que a los pedidos se le agreguen platos hasta que se confirmen, con lo cual, la idea es que mientras esta en pendiente te van a llegar los guardar_plato como consecuencia de los añadir_plato en la app ;)

5.- Buena pregunta, se nos escapo, deberían estar todos los platos en "Terminado" para poder finalizar un pedido

6.- Si pones un gran mutex, medio que la concurrencia la estas usando para limpiar el piso... La idea es que achiquen al mínimo la región critica, que bien puede ser la parte de estructuras administrativas, ya que una vez que tenes la página que vas a acceder, solo ese hilo debería acceder a esa página.

Abrazo a la distancia!

@nico-abram
Copy link
Author

Hola Damian! Gracias por las respuestas

Creo que pregunte mal la pregunta 1: Quize decir pasar a memoria principal desde swap de ser necesario, ya que para leer el nombre del plato tiene que acceder a los datos de la pagina, un caso similar al de la pregunta 3 que necesitaria leer

Sobre la 4, entonces habria que validar que este en estado pendiente el pedido?

Sobre la 6: Si, pasa que estuve viendo masomenos como encarar ese tema y agregaba mucha complejidad. Era mas que nada para saber si llegamos a tener una solucion que masomenos funciona si hacer algo asi era razon como para desaprobrar el TP

Saludos!

@ncoen97
Copy link

ncoen97 commented Sep 27, 2020

Buenas.
1/3. Siempre que se accede a una pagina se actualiza el timestamp de esa pagina. Y si, van a tener que traer las paginas de memoria para leer los platos.
4. Si, está bien hacer hacer esa validación.
6. En la teoría vemos que siempre la sección critica tiene que ser lo menor posible. Piensen que si pusieran un mutex que engloba todas las operaciones de las consultas que reciben, básicamente el proceso multihilo pasaría a ejecutar un hilo a la vez (y justamente no es la idea).
Saludos!

@nico-abram
Copy link
Author

Buenas! Gracias, cierro issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants