Subo el final de Sistemas operativos que se tomó hoy. Perdón que sea foto, pero al menos se ve bien =)

Saludos!

   

Gracias aye !!! Tengo que hacer la monumental para llegar al martes pero al otro martes llego tranquilo, de este verano no tiene que pasar !!

Que lindo final, la verdad que estaba para rendirse, lastima que no llegue, en fin, espero que el martes que viene sea un final parecido porque estuvo bastante balanceado

alguien sabe el ultimo punto ? el 3 c)

porque en la cursada no vi ni hard links ni symbolic links, lo unico que se lo se de unos apuntes que encontre por ahi, que explican que son pero no para que sirven

Todavia no entiendo como se resuelve el de frames:

Tenes 32 bits de direccionamiento , 10 bits van para el offset

Te quedan 22 bits para las paginas , osea tenes 2¨22 paginas, cada entrada ocupa 4 bytes asique:

2¨22 x 2 ¨2 .

Y despues nose!

Direcciones lógicas de 32 bits
Tamaño de página de 1 Kbyte = 2^10 bytes → se necesitan 10 bits para el desplazamiento
El número máximo de páginas será de 2 (32 -10)= 2^22 páginas
La tabla de páginas ocupa 2^22 .4 bytes = 16Mbytes
En total haría falta 16Mbytes/1Kbyte=16.2^10 páginas o marcos

Con el ejercicio de frames, hasta ahí vas bien, ahora lo que tenes es cuantos bytes ocupa la tabla de paginas, pero lo que necesitas son cuantos frames, y suponiendo que el tamaño de un frame es igual al tamaño de una página, entonces dividis los bytes por el tamaño de pagina (1k) y ya tenes la cantidad de frames máxima.

Gonza, me imagino que te referis al punto 2-c. Yo lo que pense fue lo siguiente:
Un hard link es como si copiaras el inodo del archivo y lo pegaras en otro directorio, entonces hay dos directorios que tienen el mismo archivo, aunque son dos inodos distintos con punteros a los mismos bloques de datos. El problema con esto es que si no tuvieras los permisos del archivo en el inodo, si esta info estuviera en otra parte, no podes regular bien el acceso al archivo, porque si es por ejemplo un .exe, con el inodo copiado vos podes acceder directamente a los datos de ese archivo y no tenes como verificar que solo podes ejecutar el archivo y no leer o escribir. Entonces el problema es que con hard links accedes directamente al archivo.
Un symbolic link, es un archivo distinto con un inodo distinto que tiene en su contenido el puntero al archivo original. Ahora no me acuerdo si era que tenia un puntero al inodo o si tenia el nombre del archivo, pero la gracia seria que tenes que pasar por el original para acceder al archivo y ahi si se puede verificar los permisos ya sea si estan en el directorio original o si estan en el inodo.

un regalo, lastima que no me presenté

(20-02-2013 18:07)nadiafaya escribió:  Con el ejercicio de frames, hasta ahí vas bien, ahora lo que tenes es cuantos bytes ocupa la tabla de paginas, pero lo que necesitas son cuantos frames, y suponiendo que el tamaño de un frame es igual al tamaño de una página, entonces dividis los bytes por el tamaño de pagina (1k) y ya tenes la cantidad de frames máxima.

Gonza, me imagino que te referis al punto 2-c. Yo lo que pense fue lo siguiente:
Un hard link es como si copiaras el inodo del archivo y lo pegaras en otro directorio, entonces hay dos directorios que tienen el mismo archivo, aunque son dos inodos distintos con punteros a los mismos bloques de datos. El problema con esto es que si no tuvieras los permisos del archivo en el inodo, si esta info estuviera en otra parte, no podes regular bien el acceso al archivo, porque si es por ejemplo un .exe, con el inodo copiado vos podes acceder directamente a los datos de ese archivo y no tenes como verificar que solo podes ejecutar el archivo y no leer o escribir. Entonces el problema es que con hard links accedes directamente al archivo.
Un symbolic link, es un archivo distinto con un inodo distinto que tiene en su contenido el puntero al archivo original. Ahora no me acuerdo si era que tenia un puntero al inodo o si tenia el nombre del archivo, pero la gracia seria que tenes que pasar por el original para acceder al archivo y ahi si se puede verificar los permisos ya sea si estan en el directorio original o si estan en el inodo.

en realidad el hard link habia encontrado esto (en un mail de E. Masoero) en los apuntes:

Cita:Crear un hard link a ese archivo: sería otra entrada en el mismo u otro directorio que apunta al inodo del archivo en cuestión. Si la entrada estuviera en el mismo directorio, tendria que tener otro nombre. (Tendriamos entonces 2 entradas de directorios que apuntan al mismo inodo).

es un solo inodo

mientras que el soft link

Cita:- Crear un soft link a ese archivo: sería un nuevo archivo de tipo "soft link" que en su contenido tiene la ruta del archivo al que apunta. Esto implica un nuevo inodo para ese nuevo archivo, y obviamente una nueva entrada de directorio que apunte a ese inodo recientemente creado.(Tendríamos entonces 2 entradas de directorios, cada una apuntando a un inodo distinto).

una manera facil (?) de entender el concepto para mi, es como si fuera un acceso directo de windows (un .ink) (no se si es asi, pero a mi me sirve )

El hard link no me termina de cerrar del todo.



En cuanto a la respuesta.. si es un hard link es una entrada que apunta al inodo, asique si no tengo los permisos en ese inodo, no puedo regular su acceso.. pero para el soft link no seria lo mismo ? Digo, es un inodo que apunta al inodo del archivo a abrir.. pasaria lo mismo, si en el inodo del archivo original no tengo los permisos, no puedo regular el acceso

el algoritmo del banquero evita que se compla solamente la condicion de retencion y espera no? con eso previene el deadlock

Ah entonces contesté cualquier cosa, je.

Ok, la cosa puede que sea asi: deben haber dos opciones para guardar los permisos o lo guardas en la entrada del directorio o lo guardas en el inodo. Si lo guardas en la entrada de directorio, con los symbolic link no hay problema porque como tienen solo la ruta del archivo van a tener que pasar por esa entrada de directorio.... en cambio con los hard link tienen una entrada de directorio distinta. Asi que necesariamente tiene que estar en el inodo del archivo.

Perdon que le pifie en la otra respuesta

EN los V o F que pondrian?

ahora si. Gracias

---

(20-02-2013 19:02)coolerking escribió:  EN los V o F que pondrian?

Los V o F aca los tenes resueltos y discutidos

http://www.campusvirtual.frba.utn.edu.ar...php?d=9065

saludos!

---

por si no te acordas tu usuario (puede pasar) y para que queden aca, lo que un pibe puso :

Cita:1) Falso. Los algoritmos de planificación se pueden utilizar para planificar tanto hilos KLT/ULT como procesos. Lo que varía es quién hace esa planificación (si el SO o la biblioteca de libros).

2) Falso. Los archivos de memoria virtual generalmente están asignados continuamente, al contrario de los archivos regulares de los filesystems más populares.

3) Verdadero. El algoritmo del banquero exige que se conozcan de antemano los recursos que los procesos necesitarán para así establecer un orden de ejecución de manera que se evite el interbloqueo.

4) En ésta no estoy seguro con que se refiera a que las "el valor de las variables globales puede ser distinto". Si se refiere al momento de hacer el fork, el hijo tiene todo igual al padre así que es falsa. Si se refiere a que el hijo después puede modificar éstos valores, es verdadera, aunque el hijo y el padre no comparten las variables.

5) Verdadero. Las interrupciones permiten que la CPU esté realizando otra tarea hasta que se le notifica por éste medio que ocurrió un suceso que debe atender. Agregándole la DMA, prácticamente se desacopla al CPU de la tarea de tratar entradas y salidas.

con la 1, 4 y 5 estoy de acuerdo, con las otras 2 no se todavia porque no estudie esa parte, estoy avanzando

En la parte practica el 2 a, hay q suponer un tamaño de bloque o no y me estoy olvidando de algo?

(20-02-2013 19:02)gonnza escribió:  ahora si. Gracias

---

(20-02-2013 19:02)coolerking escribió:  EN los V o F que pondrian?

Los V o F aca los tenes resueltos y discutidos

http://www.campusvirtual.frba.utn.edu.ar...php?d=9065

saludos!

---

por si no te acordas tu usuario (puede pasar) y para que queden aca, lo que un pibe puso :

Cita:1) Falso. Los algoritmos de planificación se pueden utilizar para planificar tanto hilos KLT/ULT como procesos. Lo que varía es quién hace esa planificación (si el SO o la biblioteca de libros).

2) Falso. Los archivos de memoria virtual generalmente están asignados continuamente, al contrario de los archivos regulares de los filesystems más populares.

3) Verdadero. El algoritmo del banquero exige que se conozcan de antemano los recursos que los procesos necesitarán para así establecer un orden de ejecución de manera que se evite el interbloqueo.

4) En ésta no estoy seguro con que se refiera a que las "el valor de las variables globales puede ser distinto". Si se refiere al momento de hacer el fork, el hijo tiene todo igual al padre así que es falsa. Si se refiere a que el hijo después puede modificar éstos valores, es verdadera, aunque el hijo y el padre no comparten las variables.

5) Verdadero. Las interrupciones permiten que la CPU esté realizando otra tarea hasta que se le notifica por éste medio que ocurrió un suceso que debe atender. Agregándole la DMA, prácticamente se desacopla al CPU de la tarea de tratar entradas y salidas.

con la 1, 4 y 5 estoy de acuerdo, con las otras 2 no se todavia porque no estudie esa parte, estoy avanzando

1) F , siempre y cuando las ULTs tengan las bibliotecas correspondientes.

2) va por el tema del area de intercambio.

3) F !! El algoritmo del banquero te asegura pasar de un estado seguro a otro estado seguro , no te puede afirmar en ningún momento si hay deadlock!!

4) El stack no se copia , las variables globales me parece que si.

5) Yo lo encare por el tema de que las interrupciones permite el bloqueo de un proceso ( pasa a wait ) por lo que termina mejorando la eficiencia del procesamiento , no la de E/S

La 5 y 3 me las dieron bien , el resto es segun lo q me dijeron