miércoles, 14 de septiembre de 2011

Practical Presentation 1

This is the explanation for the practical part 1.

We use the nachos java version 5.0 to test the practical assignments

For this presentation we've implemented a runnable program that shows the use of locks on the unbounded-buffer consumer-producer problem.

I didn't use any slide, i only showed my code to the classroom, compiled it and finally, execute my program.

On the Lock code, i used the one that nachos provide in his tar, and i just add two lines to check the execution without debug parameters.

These are the lines that i added:

in the acquire function
  System.out.println(" acquire successful by thread: "+ KThread.currentThread());

in the release function
 System.out.println(" release successful by thread: "+ KThread.currentThread());


the link to the Locks source code is here
(also you can check on /nachos/threads/Locks.java)

This is the code that i wrote:

package nachos.threads;
import nachos.threads.*;

public class Prueba{

private static Lock l = null;
private static Lock l1 = null;
private static int in_stock = 0;

public static class Producer implements Runnable{

     private KThread currentThread = null;

	public Producer(){ // constructor
	}	

	public void run(){ //metodo run, lo que hace mi programa
		System.out.println("\nThe Producer start...");		
			l.acquire();
			in_stock++;
			System.out.println("the producer make 1 item, now there are "+in_stock+" in stock."); 
			l.release();
			this.currentThread.yield(); 
         }
   }

public static class Consumer implements Runnable{

     private KThread currentThread = null;

	public Consumer(){ //constructor
	}	

	public void run(){ //metodo run, lo que hace mi programa
		System.out.println("\nThe Consumer start...");
		   l.acquire();
			while(in_stock <= 0){
			    currentThread.sleep(); }
			l1.acquire();
			  in_stock--; 
			l1.release();
			  System.out.println("the consumer take 1 item, now there are "+in_stock+" in stock.");
		     l.release();
			this.currentThread.yield(); 
	
         }
   }

	 public static void start() {
	
		l = new Lock();
		l1 = new Lock();

		while(true){
		try{
  			Thread.currentThread().sleep(2000);
		} catch(Exception e){ }
		new KThread(new Producer()).setName("Producer").fork(); 
		new KThread(new Consumer()).setName("Consumer").fork();

		new Producer().run();
		new Consumer().run();    }
 		}
}
  
Finally, i modify the nachos code because the "*** thread 'x' looped 'x' times" gives me headache, so i opened the ThreadedKernel.java and then i comment the line were  KThread.selfTest() is called for the ThreadedKernel and also i added the starter method of my class here :)

public void selfTest() {
	//KThread.selfTest();
	//Semaphore.selfTest();
	//SynchList.selfTest();
	Prueba.start();
	if (Machine.bank() != null) {
	    ElevatorBank.selfTest();
	}
    }
 
last edit 15/09/2011
changed> line x,x,x, on the Prueba.java. thanks Juan carlos.
changed> grammar and spelling (attempt to improve)

17 comentarios:

  1. Que tipos de problemas te enfrentaste al utilizar la verison de java en nachos?

    ResponderEliminar
  2. Puedes mostrar como hiciste para compilar esta versión de nachos? Me gustaría intentar también con esa versión :D

    ResponderEliminar
  3. Pues ninguno erick, Todo fue super sencillo al descargarlo, compilarlo y ejecutar los programas.
    el punto malo de usar nachos(java) es que no hay casi nada de ayuda ni documentación sobre la versión de java, lo cual hace difícil el desarrollo de programas.

    Subí un tutorial paso a paso Esteban, esta en entradas pasadas..

    ResponderEliminar
  4. Pero no te apures Ever, las funciones son muy parecidas, no importa si no hay documentación, si eres buen programador puedes leer la documentación que hay para nachos en C++ y realizar las adaptaciones semi-automáticamente para aplicarlas a Java. :)

    ResponderEliminar
  5. El principal problema al que nos enfrentamos con esta version es que el kernel que corre programas de usuario solo puede manejar la funcion/metodo Halt que termina NachOS y pues como eso no sirve de mucho ahi tuvimos que correr nuestros programas dentro del kernel lo cual no es lo ideal, la ventaja es que viene muy bien comentadas todas las clases, trae varios extras interesantes y el lenguaje es mas amigable.
    Sobre la documentacion en linea pues es complicado sacarle provecho ya que hay varias versiones de NachOS y la estructura, makefiles y demas tienen sus particularidades en cada una.

    ResponderEliminar
  6. Lo del método Halt() también pasa en la versión de nachOS en C++.
    Para todo lo demás, no me refiero a los Makefiles y eso... pero por cada función en C++ o C, existe, por lo menos, una forma de adaptarla y aplicarla en Java y viceversa.

    ResponderEliminar
  7. con el pseudocódigo del libro de Stallings es bastante entendible aunque este en Pascal(ediciones pasadas)...es fácil adaptarlo a C y Java chequenlo :)

    ResponderEliminar
  8. Juan Carlos segun he visto en la version de C++ es posible imprimir datos en un userprog por lo demas claro que se puede adaptar pero creo que es mas educativo entender uno mismo como funciona el sistema en java y modificarlo aunque no hace daño ver como funcionan otras versiones :)

    ResponderEliminar
  9. Pues si, no es muy difícil traducir código, pero yo y david aprendimos a usarlo explorando el código, lo cual ayuda en muchos aspectos.
    Ese seria un buen consejo para próximas entradas :) la mejor forma de entenderlo es hacerlo.

    ResponderEliminar
  10. En la version de C++ al abrir el codigo, si mal no recuerdo, del kernel viene en la documentación varios parametros que se le puede dar a nachos cuando lo ejecutas, no se si halla algo parecido.

    ResponderEliminar
  11. Si en la segunda entrada de este blog viene el README de nuestra version ahi se encuentran todos los comandos, otros parametros que lee el NachOS son los del config. Entre los comandos el que mas usamos es el -d para debugear varios procesos y esta tambien -x para correr userprograms etc, no se si te refieras a eso?

    ResponderEliminar
  12. En el código de prueba, declaran 3 locks... de acuerdo a discusiones pasadas, se entiene que uno corresponde al productor, otro al consumidor y otro para exclusión mutua, entonces:

    Si "L" es el lock de productores, "L1" el de los consumidores y "L2" el de exclusión mutua; hace falta ampliar un poco la funcion producer para que tome el lock "L" siempre y cuando sea necesario producir, y en lugar de usar "L" en la sección crítica deberían de usar "L2" que es el de exclusión para modificar el buffer, me imagino que si usan diferentes lock para acceder a la sección critica en cierto momento ambos tienen el permiso para modificar el buffer puesto que ambos tienen el lock aunque diferentes.

    SALUDOS :)

    ResponderEliminar
  13. Pues no creo que se necesite ampilar la funcion producer para nada Juan Carlos, ya que este es un unbounded buffer, el producer puede hacer cuantos items quiera.

    En cuanto a usar dos lock para proteger la seccion critica, puede que tengas razon, suena muy logico, supongo que tengo que checarlo bien despues de implementar un scheduler :)

    ResponderEliminar
  14. Bueno... exactamente no me refiero a usar 2 lock para la sección crítica, lo que me dices del producer es verdad entonces solo necesitas 2 lock en lugar de 3.

    Mientras que el producer solo necesita usar el lock de exclusión, el consumer usa el de exclusión y el de no hacer nada cuando el buffer esta vacío.

    Para lo demás:
    Mi argumento se basa en que debes usar el mismo lock para acceder a la sección critica tanto para el productor como para el consumidor y ese lock vendría siendo "L2" (exclusión mutua), ya que si al productor le estas dando permiso de acceder con "L" y al consumidor con "L2" entonces podría haber algún conflicto:

    1. El productor bloqueo "L" y accede a modificar.
    2. Nadie bloqueo "L2" entonces el consumidor puede acceder también a modificar la sección crítica ya que esta tomando un candado abierto.

    ResponderEliminar
  15. Oh bien bien, ese es el tipo de cosas con las cuales el FCFS me afecta, ya decia yo.
    Gracias!!

    ResponderEliminar
  16. Sería bueno incluir siempre números de línea en el código para facilitar la discusión. La gramática está pésima aquí, igual como la ortografía.
    Puntos extra (uno cada uno) a JC y Everardo por esta discusión.

    ResponderEliminar
  17. ¿En cual código hay que incluir números de linea?, sobre la gramática y ortografía, ¿Que parte de aquí esta pésima? Las entradas en ingles del blog y los comentarios en español aunque no son perfectos en mi opinión no creo que lleguen al nivel de pésimo.

    ResponderEliminar