PRACTICA 5
jueves, 29 de septiembre de 2011
miércoles, 28 de septiembre de 2011
posix
POSIX
(Portable Operating System Interface)
DEFINICION
Son una familia de estándares de llamadas al sistema operativo definidos por el IEEE y especificados formalmente en el IEEE 1003. Persiguen generalizar las interfaces de los sistemas operativos para que una misma aplicación pueda ejecutarse en distintas plataformas. Estos estándares surgieron de un proyecto de normalización de las API y describen un conjunto de interfaces de aplicación adaptables a una gran variedad de implementaciones de sistemas operativos.
Cuando el sistema operativo crea un proceso, el proceso en sí es un hilo de ejecución. Sin embargo se puede escribir un programa para crear muchos hilos que se ejecutan en el mismo espacio de memoria en forma paralela.
Los hilos POSIX son los más recomendables para emplear dado que son portables y tienen mejor desempeño que los procesos ligeros de UNIX.
La portabilidad de código permite que se pueda compilar y ejecutar el programa sobre otra plataforma que soporte hilos POSIX. De tal manera que el programador paraleliza su código insertando funciones de hilos POSIX, lo compila y lo ejecuta en una plataforma de un procesador o de múltiples procesadores (Por ej. en IRIX) y el mismo código lo puede compilar y ejecutar en otra plataforma (Por ej. en Solaris).
Con hilos POSIX se pueden paralelizar:
Llamadas a subrutinas o funciones.
E/S en C.
Algunas dependencias de datos usando herramientas de sincronización.
Los hilos POSIX no pueden paralelizar:
Ciclos individuales dentro de un programa (deben ser reescritos como funciones).
Pipas gráficas.
Ejemplo de uso de hilos POSIX:
/* hola.c
Programa que que genera 2 hilos POXIS para
imprimir a pantalla "hola mundo".
compilar:
cc hola.c -o hola -lpthread
*/
#include <pthread.h>
#include <stdio.h>
void* imprime_mensaje( void *ptr );
main()
{
pthread_t hilo1, hilo2;
char *mensaje1 = "hola";
char *mensaje2 = "mundo";
/* se generan 2 hilos que se ejecutaran en paralelo con el padre */
pthread_create(&hilo1, NULL, imprime_mensaje, (void*) mensaje1);
/* aquí el hilo padre puede estar haciendo otra cosa en paralelo con
los 2 hilos POSIX hijos */
/* por ejemplo: */
printf("A lo mejor esto se imprime primero... \n");
pthread_create(&hilo2, NULL, imprime_mensaje, (void*) mensaje2);
sleep(1);
exit(0);
}
void* imprime_mensaje( void *ptr )
{
char *mensaje;
mensaje = (char *) ptr;
printf("%s \n", mensaje);
pthread_exit(0);
}
Son una familia de estándares de llamadas al sistema operativo definidos por el IEEE y especificados formalmente en el IEEE 1003. Persiguen generalizar las interfaces de los sistemas operativos para que una misma aplicación pueda ejecutarse en distintas plataformas. Estos estándares surgieron de un proyecto de normalización de las API y describen un conjunto de interfaces de aplicación adaptables a una gran variedad de implementaciones de sistemas operativos.
Cuando el sistema operativo crea un proceso, el proceso en sí es un hilo de ejecución. Sin embargo se puede escribir un programa para crear muchos hilos que se ejecutan en el mismo espacio de memoria en forma paralela.
Los hilos POSIX son los más recomendables para emplear dado que son portables y tienen mejor desempeño que los procesos ligeros de UNIX.
La portabilidad de código permite que se pueda compilar y ejecutar el programa sobre otra plataforma que soporte hilos POSIX. De tal manera que el programador paraleliza su código insertando funciones de hilos POSIX, lo compila y lo ejecuta en una plataforma de un procesador o de múltiples procesadores (Por ej. en IRIX) y el mismo código lo puede compilar y ejecutar en otra plataforma (Por ej. en Solaris).
Con hilos POSIX se pueden paralelizar:
Llamadas a subrutinas o funciones.
E/S en C.
Algunas dependencias de datos usando herramientas de sincronización.
Los hilos POSIX no pueden paralelizar:
Ciclos individuales dentro de un programa (deben ser reescritos como funciones).
Pipas gráficas.
Ejemplo de uso de hilos POSIX:
/* hola.c
Programa que que genera 2 hilos POXIS para
imprimir a pantalla "hola mundo".
compilar:
cc hola.c -o hola -lpthread
*/
#include <pthread.h>
#include <stdio.h>
void* imprime_mensaje( void *ptr );
main()
{
pthread_t hilo1, hilo2;
char *mensaje1 = "hola";
char *mensaje2 = "mundo";
/* se generan 2 hilos que se ejecutaran en paralelo con el padre */
pthread_create(&hilo1, NULL, imprime_mensaje, (void*) mensaje1);
/* aquí el hilo padre puede estar haciendo otra cosa en paralelo con
los 2 hilos POSIX hijos */
/* por ejemplo: */
printf("A lo mejor esto se imprime primero... \n");
pthread_create(&hilo2, NULL, imprime_mensaje, (void*) mensaje2);
sleep(1);
exit(0);
}
void* imprime_mensaje( void *ptr )
{
char *mensaje;
mensaje = (char *) ptr;
printf("%s \n", mensaje);
pthread_exit(0);
}
jueves, 22 de septiembre de 2011
programa dos
DIBUJAR ARBOL
preguntas
¿Por que aparecen menajes repetidos?
R= aparecen por que se llama a la función FORK la cual hace procesos y los hijos son la copia exacta del primer proceso nada mas se diferencian por (PID y el espacio en memoria).
¿Que es lo que observas?
R= Observo el como trabaja las llamadas al sistema a partir de la función FORK el comportamiento del proceso padre se copia en la zona de memoria del proceso hijo.
La forma en que un proceso arranca a otro es mediante una llamada al sistema fork o clone.
¿Por que?
R= por que los procesos ejecutados desde el shell y la memoria esto es lo que genera a partir del código proporcionado. existe otra llamada al sistema que es clone es mucho más genérica y flexible que el fork, ya que nos permite definir qué van a compartir los procesos padre e hijo.
¿Por que aparecen menajes repetidos?
R= aparecen por que se llama a la función FORK la cual hace procesos y los hijos son la copia exacta del primer proceso nada mas se diferencian por (PID y el espacio en memoria).
¿Que es lo que observas?
R= Observo el como trabaja las llamadas al sistema a partir de la función FORK el comportamiento del proceso padre se copia en la zona de memoria del proceso hijo.
La forma en que un proceso arranca a otro es mediante una llamada al sistema fork o clone.
¿Por que?
R= por que los procesos ejecutados desde el shell y la memoria esto es lo que genera a partir del código proporcionado. existe otra llamada al sistema que es clone es mucho más genérica y flexible que el fork, ya que nos permite definir qué van a compartir los procesos padre e hijo.
lunes, 19 de septiembre de 2011
practica 1
programa 1
preguntas
1.-¿por que aparecen mensajes repetidos?
se llama la función fork, esta genera un duplicado del proceso actual. El duplicado comparte los valores actuales de todas las variables, ficheros y otras estructuras de datos. La llamada a fork retorna al proceso padre el identificador del proceso hijo y retorna un cero al proceso hijo.
2.-¿que observas?
que el proceso tiene un numero mayor que el padre como se muestra en la pantalla
2128
2127
2127
2126
2126
2103
3.-¿por que?
La forma en que un proceso arranca a otro es mediante una llamada al sistema fork o clone.
1. La función fork de la librería libc coloca los parámetros de la llamada
en los registros del procesador y se ejecuta la instrucción INT 0x80.
2. Se conmuta a modo núcleo y, mediante las tablas IDT y GDT, se llama
a la función sys_call.
3. La función sys_call busca en la sys_call_table la dirección de la
llamada al sistema sys_fork
SRANDOM
Funcion en c estadar llamada random(). Si quieres generar un numero aleatorio deberas utilizar srand() y rand(). Para hacer uso de ellas debes incluir stdlib.h
delay () o sleep ()
<windows.h> Sleep() // retraso en milisegundos
<dos.h> sleep() // retraso en segundos.
domingo, 11 de septiembre de 2011
google chrome y android
Google presentó Chrome OS
Como quedó clarísimo, el sistema operativo será 100% para trabajar con la nube. Nada de instalar aplicaciones en el sistema. Todo lo que haremos lo haremos a través de una pantalla que será prácticamente igual a la del actual navegador. De hecho, para que se den una idea del extremo al que lo llevaron, cuando conectemos una cámara digital se abrirá una pantalla de este “navegador” y nos mostrará qué hay dentro de ella.
Para realizar este OS la empresa se siguió basando en las típicas características que podemos ver en todos sus proyectos: simplicidad, velocidad y seguridad.
La simplicidad ya podrán imaginársela porque no habrá mucho más que la ventana de un navegador con el cual controlaremos todas las funciones del sistema operativo.
La velocidad, al manejar absolutamente todas las aplicaciones en la nube y solamente funcionar con discos SSD será extrema. De hecho, en la presentación oficial en Mountain View mostraron que desde que presionamos el botón de power hasta que nos pide que ingresemos nuestro nombre de usuario y contraseña tardó solamente 7 segundos y aseguraron que están haciendo todo lo posible para que este tiempo sea incluso menor.
Finalmente está la seguridad. Al no poder instalar sistemas binarios y aplicaciones externas no habrá nada más en el sistema que unos cuantos archivos de caché que sincronizarán con la nube. Esto quiere decir que no habrá sistemas que explotar más que el núcleo de Google Chrome y, como explicaron, el núcleo lo conocen suficientemente para poder arreglarlo en cuestión de horas.
La simplicidad ya podrán imaginársela porque no habrá mucho más que la ventana de un navegador con el cual controlaremos todas las funciones del sistema operativo.
La velocidad, al manejar absolutamente todas las aplicaciones en la nube y solamente funcionar con discos SSD será extrema. De hecho, en la presentación oficial en Mountain View mostraron que desde que presionamos el botón de power hasta que nos pide que ingresemos nuestro nombre de usuario y contraseña tardó solamente 7 segundos y aseguraron que están haciendo todo lo posible para que este tiempo sea incluso menor.
Finalmente está la seguridad. Al no poder instalar sistemas binarios y aplicaciones externas no habrá nada más en el sistema que unos cuantos archivos de caché que sincronizarán con la nube. Esto quiere decir que no habrá sistemas que explotar más que el núcleo de Google Chrome y, como explicaron, el núcleo lo conocen suficientemente para poder arreglarlo en cuestión de horas.
Otro de los temas más importantes es el hardware. Remarcaron que Chrome OS no podrá instalarse en cualquier ordenador, sino en los elegidos y desarrollados especialmente para este sistema. Si bien esto me parece una contra importantísima, la razón por la cual Google hace todo esto está clarísima: no quieren que el rendimiento sea menor al que aseguran. Si a un ordenador le ponemos un disco HDD en vez de uno SSD la velocidad se notará mucho y esto es lo que la empresa no quiere que suceda.
android
android es y seguira siendo un sistema de codigo abierto
El director de plataformas móviles de Google y responsable de Android, Andy Rubin, ha publicado un comunicado defendiendo que Android sigue siendo "una plataforma de código abierto" a la vez que ha prometido que "se liberará el código fuente cuando esté listo".
El revuelo generado por la decisión de Google de no facilitar por el momento el acceso al código fuente de la versión 3.0 de Android ha obligado a Andy Rubin a pronunciarse. Los desarrolladores privados han acusado a Google de limitar el sentido abierto de Android, pero Rubin ha explicado que "desde 2008 el Android ha crecido mucho" y asegura que desde Google "han mantenido el compromiso de fomentar el desarrollo de la plataforma".
La intención de la compañía es tener más control sobre el sistema en su fase inicial porque las prioridades de la compañía son "la calidad y la coherencia". El miedo de Google es que la adaptación del sistema a múltiples equipos haga peligrar la calidad del producto, provocando fallos de compatibilidad con aplicaciones de terceros.
Las palabras de Andy Rubin apuntan directamente a los experimentos de desarrolladores privados que habían intentado implantar la versión 3.0 de Android en 'smartphones'. En su día Google comentó que era un peligro porque por el momento el sistema no estaba optimizado para ello. Todo apunta a que para evitar este tipo de comportamientos, Google ha decidido no publicar su código.
Andy Rubin ha querido destacar que el sistema seguirá evolucionando. "Los fabricantes de dispositivos tienen libertad para modificar Android y personalizarlos a sus terminales", y ha confirmado que su equipo está "trabajando duro para llevar Honeycomb a los teléfonos", y cuando el trabajo esté hecho "publicarán el código".
El revuelo generado por la decisión de Google de no facilitar por el momento el acceso al código fuente de la versión 3.0 de Android ha obligado a Andy Rubin a pronunciarse. Los desarrolladores privados han acusado a Google de limitar el sentido abierto de Android, pero Rubin ha explicado que "desde 2008 el Android ha crecido mucho" y asegura que desde Google "han mantenido el compromiso de fomentar el desarrollo de la plataforma".
La intención de la compañía es tener más control sobre el sistema en su fase inicial porque las prioridades de la compañía son "la calidad y la coherencia". El miedo de Google es que la adaptación del sistema a múltiples equipos haga peligrar la calidad del producto, provocando fallos de compatibilidad con aplicaciones de terceros.
Las palabras de Andy Rubin apuntan directamente a los experimentos de desarrolladores privados que habían intentado implantar la versión 3.0 de Android en 'smartphones'. En su día Google comentó que era un peligro porque por el momento el sistema no estaba optimizado para ello. Todo apunta a que para evitar este tipo de comportamientos, Google ha decidido no publicar su código.
Andy Rubin ha querido destacar que el sistema seguirá evolucionando. "Los fabricantes de dispositivos tienen libertad para modificar Android y personalizarlos a sus terminales", y ha confirmado que su equipo está "trabajando duro para llevar Honeycomb a los teléfonos", y cuando el trabajo esté hecho "publicarán el código".
miércoles, 7 de septiembre de 2011
aspectos historicos del desarrollo de los Sistemas Operativos
Un sistema operativo es un conjunto de programas destinado a permitir el uso apropiado de las partes físicas del ordenador hardware, y de esta manera interactuar con el usuario. Los principales objetivos de los sistemas operativos es lograr que el sistema de computación se use de manera cómoda y que el hardware del computador se emplee de manera eficiente
Los primeros computadores eran grandes máquinas que se operaban desde una consola. El programador escribía un programa y luego lo controlaba directamente. el programa se cargaba manualmente en la memoria, desde los interruptores del tablero frontal, desde una cinta de papel o desde tarjetas perforadas. Luego se pulsaban los botones adecuados para establecer la dirección de inicio y comenzar la ejecución del
programa. Mientras este se ejecutaba, el programador-operador lo podía supervisar observando las luces en la consola.
programa. Mientras este se ejecutaba, el programador-operador lo podía supervisar observando las luces en la consola.
Con la creación de los circuitos LSI -integración a gran escala-, chips que contenían miles de transistores
en un centímetro cuadrado de silicio, empezó el auge de los ordenadores personales. En éstos se dejó un poco de lado el rendimiento y se buscó más que el sistema operativo fuera amigable, surgiendo menús, e
interfaces gráficas.
en un centímetro cuadrado de silicio, empezó el auge de los ordenadores personales. En éstos se dejó un poco de lado el rendimiento y se buscó más que el sistema operativo fuera amigable, surgiendo menús, e
interfaces gráficas.
TIPOS DE GESTION DE PROCESOS
Esto reducía la rapidez de las aplicaciones, pero se volvían más prácticos y simples para los usuarios. En esta época, siguieron utilizándose lenguajes ya existentes, como Smalltalk o C, y nacieron otros nuevos, de los cuales se podrían destacar: C++y Eiffel
dentro del paradigma de la orientación a objetos, y Haskell y Miranda en el campo de la programación declarativa.
SISTEMAS POR LOTES
El rasgo característico de un sistema por lotes es la ausencia de interacción entre el usuario y el trabajo mientras éste se ejecuta. El trabajo se prepara y se envía. Tiempo después aparece la salida.
TIEMPO COMPARTIDO
En estos sistemas los programas de los distintos usuarios residen en memoria. Al realizar una operación de E/S los programas ceden la CPU a otro programa, al igual que en la multiprogramación. Pero, a diferencia de ésta, cuando un programa lleva cierto tiempo ejecutándose el sistema operativo lo detiene para que se ejecute otra aplicación.
TIEMPO REAL
Estos sistemas se usan en entornos donde se deben aceptar y procesar en tiempos muy breves un gran número de sucesos, en su mayoría externos al ordenador. Si el sistema no respeta las restricciones de tiempo en las que las operaciones deben entregar su resultado se dice que ha fallado.
ARQUITECTURA DE UN SISTEMA OPERATIVO
Kernel monolítico:
La estructura de esta arquitectura es simplemente no tener ninguna. A nivel de núcleo no se produce ninguna abstracción, es decir, si un procedimiento necesita a otro es libre de hacerlo en cualquier momento. Fue el primer enfoque en la historia, el resto son evoluciones. Microkernel o micronúcleo:
En este caso, el S.O. se ocupa solo de unas pocas funciones, reduciendo el núcleo a su mínima expresión. El resto de funciones pasan a estar en el espacio de usuario.
Máquinas virtuales:
El primer sistema con esta esta arquitectura nació con la idea de separar completamente las dos funciones características de un S.O. de tiempo compartido: multiprogramación y un interfaz más apropiado que el del puro HW. El centro del sistema, también conocido como monitor de la máquina virtual, se ejecuta directamente sobre el propio HW, encargándose de la multiprogramación. De esta forma, ofrece al nivel superior varias máquinas virtuales, que son copias exactas del hardware, por lo que se puede dar el caso de ejecutar varios S.O. sobre cada una de ellas.
Suscribirse a:
Entradas (Atom)