Seguimos buscando a Arshak. Ayudanos compartiendo!
Encuesta no oficial de docentes
Resultados de la encuesta no oficial de docentes
Probaste el SIGA Helper?

Donar $100 Donar $200 Donar $500 Donar mensualmente


Enviar respuesta 
 
Calificación:
  • 0 votos - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Buscar en el tema
Final Operativos 26/02/2013
Autor Mensaje
Koren Sin conexión
Campeon del cubo Rubik
Sin estado :(
****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 123
Agradecimientos dados: 3
Agradecimientos: 17 en 6 posts
Registro en: Feb 2011
Mensaje: #1
Final Operativos 26/02/2013 Finales Sistemas Operativos
Alguien q lo tenga o se acuerde/sepa q tomaron?

Saludos y gracias!
Otros adjuntos en este tema
.pdf  Final_2013-02-26.pdf ( 446,3 KB / 327) por gonnza
27-02-2013 12:19
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] Koren recibio 6 Gracias por este post
Desert69 (01-03-2013), macedojosea (10-03-2013), fedetubi (14-03-2013), sofidw (02-02-2014), Yumbo (02-02-2014), reLlene (27-03-2014)
Heidad Sin conexión
Campeon del cubo Rubik
Sin estado :(
****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 171
Agradecimientos dados: 5
Agradecimientos: 112 en 16 posts
Registro en: Feb 2009
Mensaje: #2
RE: Final Operativos 26/02/2013
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).
(Este mensaje fue modificado por última vez en: 27-02-2013 13:00 por Heidad.)
27-02-2013 12:57
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Agro Sin conexión
Presidente del CEIT
Su marca puede estar aquí
**********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 6.760
Agradecimientos dados: 252
Agradecimientos: 888 en 293 posts
Registro en: Jul 2008
Facebook Twitter
Mensaje: #3
RE: Final Operativos 26/02/2013
Igual el mutex lo necesitas porque si no, cuando alguien esta leyendo puede haber otro que este poniendo

[Imagen: digitalizartransparent.png]
27-02-2013 13:37
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Koren Sin conexión
Campeon del cubo Rubik
Sin estado :(
****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 123
Agradecimientos dados: 3
Agradecimientos: 17 en 6 posts
Registro en: Feb 2011
Mensaje: #4
RE: Final Operativos 26/02/2013
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 =P

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 =P
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
27-02-2013 14:07
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] Koren recibio 1 Gracias por este post
DarkCrazy (28-09-2015)
gonnza Sin conexión
User Verde

*********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 17.356
Agradecimientos dados: 900
Agradecimientos: 887 en 356 posts
Registro en: Mar 2010
BlogSpot Google+ YouTube
Mensaje: #5
RE: Final Operativos 26/02/2013
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


Archivo(s) adjuntos
.pdf  Final_2013-02-26.pdf (Tamaño: 446,3 KB / Descargas: 327)

[Imagen: v34BEFt.gif]
(Este mensaje fue modificado por última vez en: 27-02-2013 14:52 por gonnza.)
27-02-2013 14:34
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] gonnza recibio 1 Gracias por este post
Imakuni (02-03-2013)
Koren Sin conexión
Campeon del cubo Rubik
Sin estado :(
****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 123
Agradecimientos dados: 3
Agradecimientos: 17 en 6 posts
Registro en: Feb 2011
Mensaje: #6
RE: Final Operativos 26/02/2013
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 =P
27-02-2013 15:27
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
gonnza Sin conexión
User Verde

*********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 17.356
Agradecimientos dados: 900
Agradecimientos: 887 en 356 posts
Registro en: Mar 2010
BlogSpot Google+ YouTube
Mensaje: #7
RE: Final Operativos 26/02/2013
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

[Imagen: v34BEFt.gif]
27-02-2013 15:42
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
lino Sin conexión
Empleado del buffet
Sin estado :(
*

-----
-----

Mensajes: 1
Agradecimientos dados: 0
Agradecimientos: 1 en 1 posts
Registro en: Feb 2013
Mensaje: #8
RE: Final Operativos 26/02/2013
(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)
}



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

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
27-02-2013 17:57
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] lino recibio 1 Gracias por este post
DarkCrazy (28-09-2015)
gonnza Sin conexión
User Verde

*********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 17.356
Agradecimientos dados: 900
Agradecimientos: 887 en 356 posts
Registro en: Mar 2010
BlogSpot Google+ YouTube
Mensaje: #9
RE: Final Operativos 26/02/2013
sisis por eso mas arriba, exactamente 1 post (=P) te dije que habia entendido mal el enunciado, que habia interpretado que 1 solo proceso podia grabar en el buffer

[Imagen: v34BEFt.gif]
27-02-2013 18:43
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Alejandro Sin conexión
Militante
nada
***

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 85
Agradecimientos dados: 5
Agradecimientos: 269 en 22 posts
Registro en: Apr 2008
Mensaje: #10
RE: Final Operativos 26/02/2013
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...
01-03-2013 00:45
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] Alejandro recibio 1 Gracias por este post
CarooLina (22-05-2015)
gonnza Sin conexión
User Verde

*********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 17.356
Agradecimientos dados: 900
Agradecimientos: 887 en 356 posts
Registro en: Mar 2010
BlogSpot Google+ YouTube
Mensaje: #11
RE: Final Operativos 26/02/2013
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)

[Imagen: v34BEFt.gif]
01-03-2013 00:54
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Alejandro Sin conexión
Militante
nada
***

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 85
Agradecimientos dados: 5
Agradecimientos: 269 en 22 posts
Registro en: Apr 2008
Mensaje: #12
RE: Final Operativos 26/02/2013
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?
(Este mensaje fue modificado por última vez en: 01-03-2013 13:41 por Alejandro.)
01-03-2013 09:13
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
AGUSTIN27 Sin conexión
Secretario de la SAE
INGENIEROOO :)
******

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 642
Agradecimientos dados: 20
Agradecimientos: 114 en 25 posts
Registro en: Feb 2010
Mensaje: #13
RE: Final Operativos 26/02/2013
(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)
}



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

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 15:05
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
gonnza Sin conexión
User Verde

*********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 17.356
Agradecimientos dados: 900
Agradecimientos: 887 en 356 posts
Registro en: Mar 2010
BlogSpot Google+ YouTube
Mensaje: #14
RE: Final Operativos 26/02/2013
(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

[Imagen: v34BEFt.gif]
(Este mensaje fue modificado por última vez en: 01-03-2013 16:03 por gonnza.)
01-03-2013 16:00
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Desert69 Sin conexión
Presidente del CEIT
Sin estado :( / "Anarquia...
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 2.477
Agradecimientos dados: 230
Agradecimientos: 345 en 206 posts
Registro en: Jun 2008
Mensaje: #15
RE: Final Operativos 26/02/2013
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 =P 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.
Spoiler: Mostrar
Acá podría haber notas de importancia. No es este el caso =)

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.
Spoiler: Mostrar
En el final no lo aclararía, pero estoy tirando fruta de lo poco que me acuerdo. Sería genial si alguien me puede decir: a) si con esto alcanza para la justificación; o b) qué haría falta agregarle para que esté completa =). Igual, se que tengo que repasar esa parte.

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.
Spoiler: Mostrar
No te engolosines con los spoilers =)

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.
Spoiler: Mostrar
Acá estoy tirando de memoria. Si es el SO y no el Hardware el que la provee, diría que es VERDADERA. Pero de memoria nomás te diría que la provee el hardware. ¿O la provee el SO apoyándose en el requisito de que el HW la provea?

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.
Spoiler: Mostrar
Fuck yeah! (?)



¿Opiniones?

[Imagen: a2.php]
[Imagen: 971aa6599664453c05cb3e42d58bbc0eo.jpg]
(Este mensaje fue modificado por última vez en: 01-03-2013 16:54 por Desert69.)
01-03-2013 16:53
Visita su sitio web Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] Desert69 recibio 2 Gracias por este post
CarooLina (06-02-2015), DarkCrazy (28-09-2015)
Buscar en el tema
Enviar respuesta 




Usuario(s) navegando en este tema: 1 invitado(s)