UTNianos

Alguien q lo tenga o se acuerde/sepa q tomaron?

Saludos y gracias!

Final 26-02-2013 de soutn.com

---

Me confundio el tema del Buffer en el 2do ejercicio , tenia 10 instancias , pero habia que tener un mutex , no lo termine de entender , ya que controlando que no se superen las 10 instancias y que se vaya vaciando el buffer antes de que se agregue otro , se controla eso ... , no lo termine de entender.

El de FAT facil , pero me confundi con los accesos , al estar la tabla en memoria , es solo 1 , yo pense que tenia que buscarlo en disco ( me base en el diagramita de silverzchatz de asignacion enlazada).

Igual el mutex lo necesitas porque si no, cuando alguien esta leyendo puede haber otro que este poniendo

Pienso q se podria hacer asi:

2 semaforos contadores (c1 y c2) c1 en 10 c2 en 0 y un mutex (m).

c1 indica cantidad q puedo poner, para controlar la restriccion de 10 elementos sin más codigo o variables comunes.
c2 indica cantidad q se pueden sacar, es el usado en situacioens comunes.

y el mutex e simplemente para controlar el acceso y que no se chotee el buffer.

Del lado del descencriptador:

Wait c1
Wait m
Depositar en buffer
Signal m
Signal c2

Del lado del notificador:

Wait c2
Wait m
Retirar resultado
Signal m
Signal c1

El 2 todabia no estoy en condiciones de resolverlo

Y la teoria seria:

1) Falso ya que el simbolick link no es el mismo archivo q A, por lo que se aumentaria su referencia (la del simbolick link).
2) Tengo q reparsarlo
3) Verdadero ya que habria que recompilar todo el codigo cada vez que se pase el programa a memoria con las direcciones correspondientes al nuevo lugar que ocupe O, meter el programa en el mismo espacio de memoria siempre.
4)Repasar
5) Pienso q verdadero, ya que si se te caga un thread perdes todo el proceso, en cambio con la multiprogramacion perderias un solo proceso. NO ESTOY SEGURO.

A seguir leyendo q el martes q viene se aprueba

Saludos

era medio parejito, igual creo que lo aprobaba, la puta madre

Cita:1) Falso ya que el simbolick link no es el mismo archivo q A, por lo que se aumentaria su referencia (la del simbolick link).
2) Tengo q reparsarlo
3) Verdadero ya que habria que recompilar todo el codigo cada vez que se pase el programa a memoria con las direcciones correspondientes al nuevo lugar que ocupe O, meter el programa en el mismo espacio de memoria siempre.
4)Repasar
5) Pienso q verdadero, ya que si se te caga un thread perdes todo el proceso, en cambio con la multiprogramacion perderias un solo proceso. NO ESTOY SEGURO.

sobre los V o F

1) coincido
2) Es verdadero, la tabla por paginacion invertida es unica, y depende de la cantidad de frames, no por proceso. La tabla de paginas por proceso (ya sea jerarquica o hash) crece segun el tamaño del proceso, porque depende de la cantidad de paginas asignadas al proceso
3) Verdadero, aunque no se que justificacion hubiese puesto. Supongo que pondria eso, de que complica y que tendria que poner siempre al programa en el mismo lugar de memoria
4) La cuatro no me acuerdo.. Me acuerdo que esa instruccion igual tenia algunos problemas, que con semaforos se solucionaban, asique, me pinta falso, pero not sure
5) Verdadero porque el multithreading exige una mayor sincronizacion, es mas complicado de programar y puede tender mas a un interbloqueos que un multiprogramacion si esta mal programado (con su consecuencia sobre la estabilidad)

---

y en el de sincro
en el lado del notificador no hace falta los 2 semaforos, porque es una unica instancia de KT, asique con el mutex nomas alcanza..
lo que te importa es que haya escrito y ya podes imprimirlo

OJO que primero hay que tener depositado algo en el buffer para imprimirlo

 while (TRUE){

rango = obtener_nuevo_rango();

r = probar_claves (rango);

wait(10sem)

wait(depo)

depositar_resultado(r, buffer);

signal(impr)

signal(10sem)

}

 while (TRUE){

wait(impr)

r2 = retirar_resultado(buffer);

signal(depo)

printf(r2);

}

con impr = 0, depo = 1, 10Sem = 10

---

si vas el martes koren, nos vemos.. yo fui este martes, pero me olvide la libreta y no pude rendir xD

---

subo el final aca asi no se tienen que loguear en el feo campus virtual

Sino me equivoco con tu alternativa no habria más que 1 elemento en el buffer, ya que para depositar 1 tienen que esperar a que se retire 1.

Espera depo, queda en 0
Hasta que no se retire, depo no sube a 1 x lo q quedan esperando los desencriptadores, el notificador retira, signalea depo y recien ahi 1 descencripatador va a poder depositar y los demas van a tener que esperar hasta un nuevo signal de depo.

(27-02-2013 14:34)gonnza escribió: [ -> ]si vas el martes koren, nos vemos.. yo fui este martes, pero me olvide la libreta y no pude rendir xD

Uhh q paja lo de la libreta jaja, sisi la idea es ir el martes

(27-02-2013 14:34)gonnza escribió: [ -> ]subo el final aca asi no se tienen que loguear en el feo campus virtual

Ya ni me acuerdo como se loguea, y mientras pueda entrar como invitado ta todo bien

Cita:Espera depo, queda en 0
Hasta que no se retire, depo no sube a 1 x lo q quedan esperando los desencriptadores, el notificador retira, signalea depo y recien ahi 1 descencripatador va a poder depositar y los demas van a tener que esperar hasta un nuevo signal de depo.

entendi mal el enunciado, ahroa que lo relei.. tenes razon

(27-02-2013 14:34)gonnza escribió: [ -> ]era medio parejito, igual creo que lo aprobaba, la puta madre

Cita:1) Falso ya que el simbolick link no es el mismo archivo q A, por lo que se aumentaria su referencia (la del simbolick link).
2) Tengo q reparsarlo
3) Verdadero ya que habria que recompilar todo el codigo cada vez que se pase el programa a memoria con las direcciones correspondientes al nuevo lugar que ocupe O, meter el programa en el mismo espacio de memoria siempre.
4)Repasar
5) Pienso q verdadero, ya que si se te caga un thread perdes todo el proceso, en cambio con la multiprogramacion perderias un solo proceso. NO ESTOY SEGURO.

sobre los V o F

1) coincido
2) Es verdadero, la tabla por paginacion invertida es unica, y depende de la cantidad de frames, no por proceso. La tabla de paginas por proceso (ya sea jerarquica o hash) crece segun el tamaño del proceso, porque depende de la cantidad de paginas asignadas al proceso
3) Verdadero, aunque no se que justificacion hubiese puesto. Supongo que pondria eso, de que complica y que tendria que poner siempre al programa en el mismo lugar de memoria
4) La cuatro no me acuerdo.. Me acuerdo que esa instruccion igual tenia algunos problemas, que con semaforos se solucionaban, asique, me pinta falso, pero not sure
5) Verdadero porque el multithreading exige una mayor sincronizacion, es mas complicado de programar y puede tender mas a un interbloqueos que un multiprogramacion si esta mal programado (con su consecuencia sobre la estabilidad)

---

y en el de sincro
en el lado del notificador no hace falta los 2 semaforos, porque es una unica instancia de KT, asique con el mutex nomas alcanza..
lo que te importa es que haya escrito y ya podes imprimirlo

OJO que primero hay que tener depositado algo en el buffer para imprimirlo

 while (TRUE){

rango = obtener_nuevo_rango();

r = probar_claves (rango);

wait(10sem)

wait(depo)

depositar_resultado(r, buffer);

signal(impr)

signal(10sem)

}

Compilar y ejecutar código

 while (TRUE){

wait(impr)

r2 = retirar_resultado(buffer);

signal(depo)

printf(r2);

}

Compilar y ejecutar código

con impr = 0, depo = 1, 10Sem = 10

---

si vas el martes koren, nos vemos.. yo fui este martes, pero me olvide la libreta y no pude rendir xD

---

subo el final aca asi no se tienen que loguear en el feo campus virtual

Cuidado porque en tu implementación de la sincronización estás limitando el uso de buffer, porque no estás dejando pasar a ningun otro proceso que no sea el notificador, por lo tanto el orden de ejecución siempre sería "producir - consumir" obligatoriamente. El buffer nunca se llenaría porque estás limitando el buffer a 1.
Es decir, no estás dejando depositar nuevos resultados al buffer sin que se haya sacado el que se puso.



La que está correcta es esta:

Del lado del descencriptador:

Wait c1
Wait m
Depositar en buffer
Signal m
Signal c2

Del lado del notificador:

Wait c2
Wait m
Retirar resultado
Signal m
Signal c1

sisis por eso mas arriba, exactamente 1 post () te dije que habia entendido mal el enunciado, que habia interpretado que 1 solo proceso podia grabar en el buffer

hola yo aprobé el martes con este final!

el de sincro es como lo dijo lino..
el de filesystem
a)
2 a la 16 por 2 a la 11 = 2 a la 27 = 128mb

b)
1 solo acceso (la fat tiene la referencia al cluster que contiene el byte)

c)
( 2 a la 27 ) / (2 a la 12) = 2 a la 15 = 32kb
hay que aumentar el tamaño del cluster a 32 kb

1) Coincido con gonnza
2) falso, puse que la jerarquica tampoco crece en proporción con el tamaño del proceso...
3) no estoy seguro si lo respondi bien..
4) no estoy seguro si lo respondi bien..
5) Coincido con gonnza

para mi que de teoria tenia bien el 1, el 2 y el 5...

pero la jerarquica depende de la cantidad de paginas.. si un proceso es mucho mas grande, tendra mas paginas (obvio, depende del tamaño de paginas, y del proceso, pero es posible)

pero estas seguro que es proporcional? que dependa no significa que sea proporcional, fijate que tenes las paginas y las paginas de las paginas, ademas ¿que pasa si la asignacion es global?

(27-02-2013 17:57)lino escribió: [ -> ]

(27-02-2013 14:34)gonnza escribió: [ -> ]era medio parejito, igual creo que lo aprobaba, la puta madre

Cita:1) Falso ya que el simbolick link no es el mismo archivo q A, por lo que se aumentaria su referencia (la del simbolick link).
2) Tengo q reparsarlo
3) Verdadero ya que habria que recompilar todo el codigo cada vez que se pase el programa a memoria con las direcciones correspondientes al nuevo lugar que ocupe O, meter el programa en el mismo espacio de memoria siempre.
4)Repasar
5) Pienso q verdadero, ya que si se te caga un thread perdes todo el proceso, en cambio con la multiprogramacion perderias un solo proceso. NO ESTOY SEGURO.

sobre los V o F

1) coincido
2) Es verdadero, la tabla por paginacion invertida es unica, y depende de la cantidad de frames, no por proceso. La tabla de paginas por proceso (ya sea jerarquica o hash) crece segun el tamaño del proceso, porque depende de la cantidad de paginas asignadas al proceso
3) Verdadero, aunque no se que justificacion hubiese puesto. Supongo que pondria eso, de que complica y que tendria que poner siempre al programa en el mismo lugar de memoria
4) La cuatro no me acuerdo.. Me acuerdo que esa instruccion igual tenia algunos problemas, que con semaforos se solucionaban, asique, me pinta falso, pero not sure
5) Verdadero porque el multithreading exige una mayor sincronizacion, es mas complicado de programar y puede tender mas a un interbloqueos que un multiprogramacion si esta mal programado (con su consecuencia sobre la estabilidad)

---

y en el de sincro
en el lado del notificador no hace falta los 2 semaforos, porque es una unica instancia de KT, asique con el mutex nomas alcanza..
lo que te importa es que haya escrito y ya podes imprimirlo

OJO que primero hay que tener depositado algo en el buffer para imprimirlo

 while (TRUE){

rango = obtener_nuevo_rango();

r = probar_claves (rango);

wait(10sem)

wait(depo)

depositar_resultado(r, buffer);

signal(impr)

signal(10sem)

}

Compilar y ejecutar código

 while (TRUE){

wait(impr)

r2 = retirar_resultado(buffer);

signal(depo)

printf(r2);

}

Compilar y ejecutar código

con impr = 0, depo = 1, 10Sem = 10

---

si vas el martes koren, nos vemos.. yo fui este martes, pero me olvide la libreta y no pude rendir xD

---

subo el final aca asi no se tienen que loguear en el feo campus virtual

Cuidado porque en tu implementación de la sincronización estás limitando el uso de buffer, porque no estás dejando pasar a ningun otro proceso que no sea el notificador, por lo tanto el orden de ejecución siempre sería "producir - consumir" obligatoriamente. El buffer nunca se llenaría porque estás limitando el buffer a 1.
Es decir, no estás dejando depositar nuevos resultados al buffer sin que se haya sacado el que se puso.



La que está correcta es esta:

Del lado del descencriptador:

Wait c1
Wait m
Depositar en buffer
Signal m
Signal c2

Del lado del notificador:

Wait c2
Wait m
Retirar resultado
Signal m
Signal c1

Una pregunta, del lado del notificador, por que hace falta tener un semaforo mutex si solo tengo una instancia? No uso el semaforo mutex cuando tengo mas de una instancia para asegurar que cualquier otra instancia no pueda acceder a la funcion en cuestion? Del lado del desencriptador uso mutex porque tengo mas de una instancia entonces poniendolo me aseguro que cualquier otro hilo no pueda usar la funcion de depositar_resultado. Pero del lado del notificador para que lo usan? Igualmente este o no este andaria bien igual pienso no?

Saludos y con el planteo de la sincronizacion coincido.

(01-03-2013 09:13)Alejandro escribió: [ -> ]pero estas seguro que es proporcional? que dependa no significa que sea proporcional, fijate que tenes las paginas y las paginas de las paginas, ademas ¿que pasa si la asignacion es global?

si la asignacion es global, lo que te dice es si le puede sacar marcos a otros procesos

pero eso te impone un limite nomas: cuando se te acaben las paginas libres (porque solo podes tomar paginas libres, o tuyas).

Sobre lo otro, si, es algo tramposa la pregunta (y caí, ahora me doy cuenta): no es proporcional, pero si cuanto mas grande es el proceso, igual o mas grande es la tabla de paginas, respecto a la tabla de otro proceso mas pequeño (que no es lo mismo, yo fui directo a esto)

---

bah, habla de "crecer proporcionalmente", es engañoso el termino jajaj pero si, viendolo desde esa perspectiva, sería falsa, no es una proporcion exacta (tipo, cada 100 mb, crece 5 paginas [tirando fruta])

---

Cita:Una pregunta, del lado del notificador, por que hace falta tener un semaforo mutex si solo tengo una instancia? No uso el semaforo mutex cuando tengo mas de una instancia para asegurar que cualquier otra instancia no pueda acceder a la funcion en cuestion? Del lado del desencriptador uso mutex porque tengo mas de una instancia entonces poniendolo me aseguro que cualquier otro hilo no pueda usar la funcion de depositar_resultado. Pero del lado del notificador para que lo usan? Igualmente este o no este andaria bien igual pienso no?

porque un desencriptador podria estar escribiendo en el buffer, y si el notificador no tiene el mutex, para verificar que el desencriptador este escribiendo, lo puede cortar a la mitad, cosa que no deberia pasar

Lo increíble es que nadie se haya preguntado por qué el PDF se titula "El Boening 777 de United Airlines surcaba sigilosamente los aires del Mar Caribe"...


Para el punto de Brutus, creo que lo haría como lino, pero con nombres bonitos c2 sería "BufferDisponible", que arranca en 10, c1 "ResultadoDisponible", en 0, y la m un mutex que arranca en 1.


En FileSystem:
1) TamañoDisco = TamañoCluster * CantidadClusters
FAT completa => Máxima cantidad de clusters => CantidadClusters = 2^16 => 64K Clusters
=> TamañoDisco = 2KiB * 64K = 128 MiB

(osea, como dijo Alejandro - revisé 5 minutos porque 2KiB * 64K me dió 32MiB... Estúpidas vacaciones )


2) Con clusters de 2KiB (2048 bytes), el byte 5125 está en el 3º cluster:
Cluster 1: byte 0 al 2047
Cluster 2: byte 2048 al 4095
Cluster 3: byte 4096 al 6143

Entonces, tengo que ubicar la posición en la FAT del primer cluster, leer el puntero al siguiente, leer el puntero al siguiente de éste, y ahí acceder al archivo.

Si la FAT y el directorio están en memoria, todas las búsquedas son en memoria, salvo el acceso al dato propiamente dicho (la lectura del tercer cluster del archivo para obtener el byte 5125), por lo que hay una única lectura en disco - el resto son en memoria.


3) Para formatear todo el disco en FAT12 manteniendo el tamaño total, habría que aumentar el tamaño del bloque.

CantidadClusters * TamañoCluster = 128 MiB
2^12 * TamañoCluster = 128 MiB
TamañoCluster = 128 MiB / 4 KiB = 32 KiB

Fragmentación interna para todos



En cuanto a la teoría:

1) FALSO. Se puede crear el hard link apuntando a S, pero el contador de hardlinks de A se mantiene intacto - aumentaría el contador de hardlinks de S.

2) VERDADERO. La tabla de paginación jerárquica crece de acuerdo al tamaño del proceso (por más que sea más paginable que la tabla simple), mientras que la tabla invertida tiene un tamaño constante.

3) VERDADERO. Si las direcciones fueran físicas (osea, no relativas a un punto base del proceso), en cada traslado del programa a un área de memoria diferente deberían o bien recalcularse todas las direcciones, o bien garantizarse siempre que al reanudar el proceso se lo ubique en la misma dirección.

4) FALSO. Compare&Exchange la provee el microprocesador, no el SO. Es más segura (las soluciones por hardware son las únicas realmente seguras) que las otras, pero es el hardware el que la provee.

5) VERDADERO. Usar múltiples procesos individuales (multiprogramación) que cooperen entre sí es más estable que usar múltiples hilos dentro de un proceso, ya que cualquier problema que tenga un hilo podría afectar al otro (comparten espacios de memoria), mientras que los procesos son independientes entre ellos.



¿Opiniones?