Práctica Nº 2 - Ingeniería Informática y de Sistemas

Universidad Nacional de San Antonio Abad del Cusco
Departamento Académico de Informática
Programación Concurrente y Distribuida
Práctica Nº 2
Acceso Concurrente a Recursos Comunes
Ing. Iván Medrano Valencia
1. Objetivo
El objetivo de esta práctica es la familiarización con la problemática que aparece
cuando dos o más procesos concurrentes interaccionan mediante el acceso a una variable o
estructura de datos compartida. En primer lugar, se plantea un sencillo problema de
procesos cooperantes en el que se ha de modificar una misma variable. Se podrá
comprobar cómo la simple realización sin hacer ninguna consideración de la concurrencia
lleva a un comportamiento anómalo. Esto llevará a la conclusión de que es necesario algún
mecanismo de exclusión mutua: mientras un proceso está accediendo a la variable
compartida hay que impedir que otros procesos puedan acceder a la misma.
La práctica consiste en diseñar un mecanismo de exclusión mutua usando únicamente las
operaciones que ya conocemos de la programación secuencial (consulta y asignación de
variables). Se podrá comprobar que el diseño de un mecanismo de exclusión mutua
utilizando sólo operaciones de lectura y escritura de variables no es nada adecuado.
2. Base Teórica Complementaria
Acciones atómicas o indivisibles
Como ya sabemos, las acciones de los procesos concurrentes quedan entrelazadas de
forma no determinista. Antes de estudiar el problema que nos ocupa es conveniente saber
cuáles son las operaciones atómicas o indivisibles que consideraremos. Las operaciones
atómicas son aquellas operaciones indivisibles que no se pueden superponer a otras
operaciones interferentes. Es decir, ningún otro proceso puede observar los efectos
(intermedios) de una acción atómica mientras ésta se realiza y ningún otro proceso puede
interferir en su ejecución.
En nuestro caso, la cuestión es ver qué operaciones podemos considerar atómicas y cuáles
no. Por ejemplo, ¿podemos considerar la sentencia en Java x = x + 1; una operación
atómica? Si analizásemos en detalle el código generado por el “compilador” de Java,
seguramente veríamos que se hacen las siguientes acciones:
a) Lectura del valor de la variable x en un registro del procesador.
b) Incremento del valor del registro.
c) Escritura del valor del registro allí donde se almacena la variable x.
Por tanto, vemos que no es una acción atómica, ya que durante su ejecución puede llegar a
interferir con otras acciones que lean o escriban en la variable x. Por otro lado, sí
consideraremos que las acciones de lectura o escritura de una variable no se pueden solapar
y por tanto serán atómicas.
3. Problema
Simular las operaciones que se hacen sobre una cuenta bancaria.
4. Práctica
Programación Concurrente y Distribuida
Acceso Concurrente a Recursos Comunes
public class CuentaBanco
{
//--atributo
public static float a_CtaBan;
public CuentaBanco()
{
a_CtaBan=0;
}
//--devuelve el saldo actual de la cuenta
public static float obtenerSaldo()
{
return a_CtaBan;
}
//-- actualiza el valor de la cuenta
public static void actualizarSaldo(float nuevoSaldo)
{
a_CtaBan= nuevoSaldo;
}
}
public class Movimiento extends Thread
{
float a_monto;
CuentaBanco a_cta;
int a_tiempo;
public Movimiento(CuentaBanco p_cta, float p_monto, int p_tiempo)
{
a_cta=p_cta;
a_monto=p_monto;
a_tiempo=p_tiempo;
}
public void run()
{
try
{
float saldo= a_cta.obtenerSaldo();//---obtiene saldo anterior
sleep(a_tiempo); //--la cajera cuenta el dinero
saldo=saldo+a_monto; //--obtiene nuevo saldo
a_cta.actualizarSaldo(saldo);
}
catch(InterruptedException e)
{
}
}
}
class AppBanco
{
public static void main(String[] arg)
2
Programación Concurrente y Distribuida
Acceso Concurrente a Recursos Comunes
{
CuentaBanco cuenta= new CuentaBanco();
Movimiento abono = new Movimiento(cuenta, 500,400);
Movimiento cargo = new Movimiento(cuenta, -300,300);
abono.start();
cargo.start();
try
{
abono.join();
cargo.join();
}
catch(InterruptedException e)
{
}
System.out.println("Saldo = "+cuenta.obtenerSaldo());
}
}
CUESTIONARIO
5. CUESTIONARIO
5.1. ¿Es correcta la ejecución del programa?
5.2. ¿Cuál es la explicación?
6. TRABAJO
Modificar el programa anterior utilizando el algoritmo de Dekker
BIBLIOGRAFÍA.
• Doug Lea
•
Deitel y Deitel
•
Ken Arnold
James Goslin
David Holmes
Milenkovic
•
•
•
“Programación Concurrente en Java”
2da. Edición.
Addison Wesley 2001.
“JAVA How to Program” 3ra. Edición Prentice Hall
1999.
“El Lenguaje de Programación JAVA”. 3ra. Edición.
Addison Wesley 2001
“Sistemas Operativos – Conceptos y Diseño” 2da. Edición.
McGraw Hill 1994.
http://www.oup-usa.org/docs Oxford University Press
http://java.sun.com/ Sun MycroSystems.
Cusco, enero de 2008
3