ESTUDIO COMPARATIVO DEL SOPORTE MULTIHILO DE JAVA VERSUS PTHREADS

JORGE A. CASTELLANOS D. Departamento de Computaci on Universidad de Carabobo FACYT Valencia, Estado Carabobo, Venezuela email: jcasteld@uc.edu.ve RESUMEN En este trabajo, se propone el estudio de dos de las interfaces de programaci on paralela de mayor uso y difusi on, como son, Pthreads de C y Java (multi-threading), con el prop osito principal de hacer m as accesible al estudiante de la Licenciatura en Computaci on de la FACYT, el tema de la programaci on multihilos, que ha sido tratado tradicionalmente c omo dif cil, proclive a errores y algo misterioso. Para la realizaci on del presente estudio se seleccion o el sistema operativo Linux debido a su Licencia GNU (de dominio p ublico), este hecho lo hace muy accesible a la comunidad docente y estudiantil de la FACYT. Este sistema, adem as tiene entre sus haberes: su compatibilidad con sistemas operativos tipo Unix y dispone de una gran cantidad de herramientas de programaci on y aplicaciones. PALABRAS CLAVE Programaci on multihilo, Pthreads, Java, Mutex, Monitor en la actualidad como los son Pthreads y Java. Esta evaluaci on le permitir a al programador, antes de iniciar el desarrollo de una aplicaci on multihilos, decidir cual de estos soportes favore por otra parte decidir ce m as a sus intereses, o el buscar otra alternativa diferente de C y Java para dar soluci on a su problema. Si bien, todos los c odigos que se recopilaron y desarrollaron para el presente trabajo, se probaron usando Linux sobre m aquinas Pentium 4 con un solo procesador, se podr an montar y evaluar con relativa facilidad usando otros sistemas operativos o tipos de m aquina (por ejemplo, multiprocesador), aunque la evaluaci on de su comportamiento puede ser el objeto de un proyecto futuro. En la primera parte se presenta la comparaci on de los dos soportes multihilos estudiados que toma en consideraci on las caracter sticas comunes y no comunes de los dos soportes multihilo bajo consideraci on. En la segunda parte del estudio se presenta un ejemplo sencillo que adem as de ilustrar el uso de las primitivas de sincronizaci on, sirve de referencia al lector para interpretar los t opicos abordados en las comparaciones y en las conclusiones. Es de notar que este art culo representa un resumen de un trabajo extenso elaborado por el mismo autor[3], donde se implement o un conjunto de programas multihilo que permitieron evaluar diversos aspectos de la programaci on multihilo, como los tiempos de ejecuci on (caso programa del agente viajero); a un cuando solamente se presentan los c odigos para uno de

1.

Introducci on

Aunque se debe reconocer que la programaci on multihilos, de por s es compleja, debido a los factores adicionales que debe tomar en cuenta el programador y tambi en a los nuevos problemas que aparecen ( nter-bloqueos y condiciones de carrera)[1], es importante disponer de una evaluaci on inicial de las facilidades e inconvenientes que presentan los soportes de programaci on multihilos de m as amplia difusi on

los programas realizados, algunas conclusiones hacen referencia a otros programas que no se presentaron en este art culo por limitaciones de espacio.

2. 2.1.

Comparaci on Java vs. Pthreads Principales diferencias

La interfaz de Java es orientada a objetos mientras que Pthreads est a orientada a funciones. Esto hace que la interfaz de Java sea m as f acil de entender. Un hilo se conceptualiza en Java como un objeto ejecut andose sobre si mismo[12]. Los hilos Pthreads ofrecen muchas m as caracter sticas que Java. Por ejemplo Java ofrece s olo un m etodo para destruir un hilo mientras que Pthreads ofrece varias funciones para el mismo prop osito. El poder los hilos de Java es su simplicidad, pocas alternativas, facilidad de uso y confort. Pthreads le da al programador un control m as preciso sobre los hilos, mientras que Java le da simplicidad y extensibilidad. Hay un sentimiento que los hilos de Pthreads son m as dif ciles de entender y programar con ellos que los hilos de Java.

run(). Cuando se crea un hilo con Pthreads, el nuevo hilo arranca autom aticamente, mientras que en Java se debe llamar expl citamente al m etodo start(). Es decir, los hilos de Java se pueden crear para un uso posterior, mientras que los hilos Pthreads deben crearse donde se necesitan para empezar su ejecuci on. Uniendo hilos: La uni on de hilos es similar en Java y Pthreads. Ambos crean una dependencia entre los dos hilos, donde un hilo espera a que el otro nalice su trabajo. Cuando un hilo termina su trabajo en Pthreads, su resultado est a autom aticamente disponible como estado de realizaci on (completion status). En Java para obtener el resultado del trabajo de un hilo que termina hay que usar una variable de clase, y almacenar el resultado en una variable de clase. En resumen, esto resulta algo m as complicado en Java que en Pthreads. Deteniendo un hilo: Java tiene solo un m etodo implementado(stop() para detener un hilo (s olo en la versi on JDK 1.0). Este m etodo puede ser llamado desde dentro de este hilo o desde otros objetos. Para llamar ste m e etodo desde otros objetos, es necesario tener una referencia de los objetos hilo para llamar stop(). En la versiones posteriores a la 1.1 (Java 2), no est a implementado el m etodo stop() porque puede dar lugar a fallos graves del sistema[12]. En contraste, el est andar Pthreads dene diferentes funciones para detener un hilo. La funci on pthread exit() puede llamarse desde el hilo mismo que se quiere detener. Las funciones pthread kill() y pthread cancel() se usan para terminar un hilo desde otros hilos[2]. Identicador del hilo: Los identicadores de hilos (ID) est an denidos en forma muy diferente en Java y en Pthreads. Un identicador de hilo en Java es una cadena (String), mientras que en Pthreads es semejante a una

2.2.

Diferencias Espec cas

Creaci on y arranque de hilos: En Java un hilo se crea instanciando un objeto thread. Los hilos Pthreads se crean llamando la funci on pthread create con las funciones espec cas que van a ser ejecutadas por el hilo. Los par ametros del nuevo hilo Pthreads est an limitados a uno, salvo que se use como par ametro una estructura. Mientras que en Java virtualmente no hay un l mite para el n umero de par ametros que tendr a el m etodo

estructura de datos opaca sobre la cual s olo puede operar un hilo de control. En Pthreads, al contrario de Java, no es posible establecer un identicador, solo se puede recuperar y comparar. En Pthreads los identicadores de hilos se establecen autom aticamente en el momento de crear el nuevo hilo. Es m as f acil comparar dos hilos en Java; en Pthreads se necesita usar una funci on (pthread equal(id1, id2)) especialmente denida para este n. Atributos de los hilos: Los atributos de los hilos son una de las mayores ventajas de los hilos Pthreads sobre los hilos de Java. Los atributos no est an disponibles en Java. Los atributos se usan para varios prop ositos. Por ejemplo la funci on pthreads attr setschedpolicy() puede establecer pol ticas de planicaci on de hilos. En este sentido los hilos Pthreads son m as controlables que los hilos de Java. Los hilos Pthreads tienen un atributo de alcance de los argumentos que se puede denir sobre m ultiples hilos, mientras que en Java no existe este atributo. Grupos de hilos: En Java, a diferencia de Pthreads, cada hilo, desde el momento de su creaci on pertenece a un grupo de hilos. esta caracter stica puede ser ventajosa para programas donde se necesita trabajar con gran cantidad de hilos, ya que los hilos se pueden hacer pertenecer a diferentes grupos y de esta forma las operaciones sobre los hilos se realizan a trav es del grupo al cual pertenecen. En Java tambi en es posible la denici on de grupos de grupos de hilos[11]. Niveles de Prioridad: Los hilos Pthreads pueden tener al menos 32 prioridades diferentes, dependiendo de la implementaci on utilizada. En Java solo hay 10 prioridades de biblioteca denidas. Pol tica de Planicaci on La pol tica de planicaci on determina como interact uan los hilos de igual prioridad. Pthreads permite

denir la pol tica de planicaci on, dependiendo del sistema operativo y de la implementaci on particular de Pthreads sobre el sistema operativo en particular. En Java no se tiene acceso a la pol tica de planicaci on, la interacci on entre m ultiples hilos en Java depende sobre qu e sistema operativo est a corriendo la m aquina virtual de Java[8].

3.

Ejemplo de programaci on

Este ejemplo de programaci on multihilo que denominaremos Suma Paralela es muy sencillo y su car acter es netamente acad emico. El objeto principal es ilustrar las t ecnicas fundamentales de programaci on multihilos. El c odigo del programa se tom o de [4] y se adapt o para este trabajo, aun cuando su versi on original es para Modula-3. El programa recibe como par ametro el n umero de componentes de un vector (N), cuyas componentes (v[i]) se generar an en forma aleatoria. El programa por su parte calcular a en paralelo la suma de todas las componentes del vector (v[i]), por supuesto usando m ultiples hilos. Es decir, el programa principal despu es de generar el vector, crear a tantos hilos como componentes denidas del vector. Cada uno de los hilos recibe como par ametro una componente del vector que sumar a a un acumulador com un s. Cuando todos los hilos hayan terminado su trabajo (sumar al acumulador el par ametro recibido), el programa principal imprime el resultado. Para implementar cada una de las versiones se tomaron en consideraci on las facilidades que provee cada interfaz, es decir, cuando se hace la implementaci on con Pthreads se usa el objeto mutex[13] mientras que para la implementaci on con Java se preere usar monitores[6] para resolver los problemas de sincronizaci on[14]. En la gura 1 se observa una salida t pica obtenida al ejecutar el programa de suma paralela. Las versiones implementadas producen una salida por pantalla equivalente a la mostrada.

jcasteld@cu-d01:/Ascenso/Pthreads\$ ./run Se sumar an 10 n umeros: 85 40 79 80 92 20 34 77 28 56 Hilo 1: sumando 85, suma 85 Hilo 2: sumando 40, suma 125 Hilo 3: sumando 79, suma 204 Hilo 4: sumando 80, suma 284 Hilo 5: sumando 92, suma 376 Hilo 6: sumando 20, suma 396 Hilo 7: sumando 34, suma 430 Hilo 8: sumando 77, suma 507 Hilo 9: sumando 28, suma 535 Hilo 10: sumando 56, suma 591 El total es 591, calls = 10

usa para garantizar el acceso exclusivo al acumulador s, que es una variable compartida por los N hilos. Cuando un hilo obtiene el mutex m mediante la funci on pthread mutex lock, este hilo puede modicar el acumulador s y al mismo tiempo tambi en evita que cualquier otro hilo obtenga el mutex hasta que el hilo actual (que posee el mutex), haya liberado el mutex m a trav es de la ejecuci on de la funci on pthread mutex unlock.
void * sum(void * arg) { int * p; p = (int *)arg; pthread_mutex_lock(&m); s = s + *p; pthread_mutex_unlock(&m); }

Figura 1. Salida para el programa de suma.

3.1.

Implementaci on con Pthreads

Para implementar este programa usando Pthreads se realiz o una versi on que ilustra el uso del objeto mutex. Pero, porqu e usar un objeto de sincronizaci on para un programa que resuelve un problema tan simple como: sumar N componentes de un vector ? Por supuesto que sumar N componentes de un vector en forma secuencial no presenta ninguna dicultad, ni amerita el uso de objetos de sincronizaci on. Los inconvenientes se presentan cuando se propone obtener una soluci on mediante una versi on paralela (multihilos). El primer problema se genera cuando denimos una variable s que va a ser compartida por N hilos que se ejecutan en paralelo. Es decir, se debe garantizar el acceso exclusivo[14] a la varible s, o sea, s olo un hilo puede acceder en forma simult anea la variable s. El segundo problema que ilustra este ejemplo es la necesidad de crear un mecanismo de sincronizaci on que permita al programa principal imprimir el resultado cuando todos los N hilos hayan nalizado. Es por esto que necesitamos hacer uso de los objetos de sincronizaci on que proporciona la interfaz de programaci on paralela. Para esta situaci on particular Pthreads nos ofrece el objeto mutex. En sentido estricto no se tendr an N hilos, sino N instancias de un mismo hilo. El c odigo de este hilo se muestra en la gura 2. La variable global m del tipo pthread mutex t, se

Figura 2. Hilo que efect ua la suma. La regi on que se dene entre la ejecuci on de las funciones pthread mutex lock y pthread mutex unlock se denomina regi on cr tica. En programaci on multihilos con Pthreads se debe tener especial cuidado en aparear correctamente estas dos funciones, para evitar caer en uno de los errores m as frecuentes[4]. Esto es, debe prestarse especial cuidado en ejecutar primero la funci on pthread mutex lock (al inicio de la regi on cr tica) y despu es la funci on pthread mutex unlock (al nal de la regi on cr tica). Este error es dif cil de detectar, de all que usualmente se agrega un sangrado adicional al c odigo contenido en la regi on cr tica como se muestra en la gura 2. Seg un se hab a comentado, el segundo problema que debemos resolver en este ejemplo es imprimir el resultado cuando todos los hilos hayan terminado su trabajo (sumar su par ametro al acumulador s). El programa principal necesita que cada uno de los hilos le informe cuando termin o su trabajo. Una posible soluci on es que cada hilo (cuando termine) incremente una variable global (que se llamar a calls) y adem as se nale al programa principal a trav es de una variable done (del tipo pthread cond t ) despu es de modicar la variable global calls. La nueva versi on que incorpora estas mejoras puede verse en la gura 3.

void * sum(void * arg) { int * p; p = (int *)arg; pthread_mutex_lock(&m); s = s + *p; pthread_mutex_unlock(&m); pthread_mutex_lock(&mm); calls ++; pthread_cond_signal(&done); pthread_mutex_unlock(&mm); }

Figura 3. C odigo mejorado del hilo sum

En el c odigo mejorado (gura 3) se observa el uso de un nuevo mutex mm que se usa para garantizar el acceso exclusivo de la variable global calls. Para proteger la variable calls se usa otro mutex para evitar caer en el problema de serializaci on que incrementa los tiempos de ejecuci on al crear cuellos de botella adicionales en detrimento de la concurrencia (o paralelismo). En este caso se debe notar que no es necesario bloquear el acceso a la variable calls, mientras se est a accediendo la variable s. De esta forma se permite a un hilo modicar la variable calls, mientras que otro hilo puede estar modicando la variable s. Cuando se necesita mejorar el rendimiento, se recomienda asignar a cada elemento o dato compartido un mutex diferente. Si bien, se conoce el c odigo que ejecuta cada uno de los hilos, se revisar a a continuaci on el c odigo del programa principal main (ver gura 4) que recibe la informaci on de los hilos para comprender el mecanismo de sincronizaci on que le permite al programa main determinar cuando todos los hilos han terminado para luego imprimir el resultado de la suma de las componentes del vector v.
main (int argc, char *argv[]){ /* Inicializa vector de N componentes */ /* Crea N hilos */ pthread_mutex_lock(&mm); while (calls != N) pthread_cond_wait(&done, &mm); pthread_mutex_unlock(&mm); printf("El total es %d\n", s); }

pthread mutex lock, el programa main genera el vector v con N componentes y crea los N hilos (que efect uan las sumas). T ecnicamente este segmento de programa puede reemplazarse por una serie de llamadas a la funci on join, pero se preere usar este mecanismo porque adem as de ser m as eciente, ya que no consume tiempo de procesador por espera ocupada (como es el caso de la funci on join), permite ilustrar el mecanismo est andar que se recomienda utilizar cada vez que un hilo debe esperar por una variable de condici on. Cuando se trabaja con variables de condici on (ver gura 3), el primer paso consiste en adquirir el mutex (mm) asociado a la variable compartida calls dentro del c odigo del hilo. Este mutex (mm) se asocia tanto a la variable calls como a la condici on done. El segundo paso es llamar a pthread cond wait dentro de un lazo while (ver gura 4), esto es porque el valor que devuelve pthread cond wait no indica con certeza el valor de su predicado, es decir, se debe re-evaluar la condici on una vez que se retorna de ella; en nuestro caso debemos re-evaluar el valor de N para estar seguros que el hilo se reasumi o porque N cambi o su valor. El lazo while y el manejo de cualquier variable asociada a la evaluaci on de la condici on (en nuestro caso N) deben estar ubicados dentro de la regi on cr tica denida por el mismo mutex (mm) que adem as es un par ametro de la funci on pthread cond wait. Al evaluar como falsa la condici on del while es porque todos los hilos han terminado y seg un lo previsto es el momento de imprimir el resultado y terminar la ejecuci on del programa main.

3.2.

Suma paralela usando Java

Figura 4. C odigo del programa principal.

Antes de proceder a llamar a la funci on

A diferencia de Pthreads, el lenguaje de programaci on Java ofrece un mecanismo de alto nivel para el manejo del problema de exclusi on mutua denominado monitor, que presenta la ventaja de ser menos proclive a errores; adem as, como el monitor est a implementado en el lenguaje de programaci on Java, facilita al programador la tarea de denir regiones cr ticas para exclusi on mutua de datos y/o funciones.

A un cuando el problema que se pretende resolver usando monitores es relativamente simple, tenemos que el c odigo en Java se torna algo complejo; posiblemente se deba al hecho que Java es una lenguaje que aparentemente no est a formulado para la soluci on de problemas peque nos. A pesar que la soluci on es algo m as complicada por la cantidad de lineas de c odigo, a diferencia del lenguaje C, el compilador de Java garantiza que el programa no se ejecutar a hasta tanto no est en resueltos casi todos los problemas que involucren inconsistencias en las denici on de las clases que conforman el programa. Si bien, el problema posiblemente se pueda plantear usando menos clases, la soluci on se presenta usando cuatro clases, sacricando cantidad de c odigo por claridad en el planteamiento y tratando de asemejar, en lo posible, la soluci on con monitores a la soluci on ya planteada con mutex (Pthreads), para facilitar al lector el seguimiento en la forma como se presenta la soluci on del problema. La primera clase propuesta se denomina Acumulador (ver gura 5) y dentro de ella se denen tres m etodos del tipo synchronized, es decir que se procesan en forma exclusiva por la m aquina virtual de Java. Por ejemplo, cuando se ejecuta el primero de ellos, los otros dos restantes no se ejecutan hasta que el primero termina su ejecuci on. El primer m etodo, sumar, suma al acumulador s el n umero entero que se le pasa como par ametro. El segundo m etodo, icalls, incrementa en 1 el valor de la variable calls. El tercer m etodo, verificar, comprueba si el valor que se le pasa como par ametro es igual a la variable de clase calls; si son iguales regresa true, sino devuelve false. La segunda clase, denominada Hilo, como lo indica su nombre (ver gura 6), contiene el c odigo que ejecutar a cada uno de los hilos responsables de sumarle al acumulador una componente del vector. Esta clase hace uso de los m etodos denidos en la clase Acumulador ya que se le pasa como uno de sus par ametros un objeto de clase Acumulador. Al hacer uso de los m etodos tipo synchronized de la clase Acumulador, se garantiza en for-

class Acumulador{ int s, calls; Acumulador() { s = 0; calls = 0; } synchronized void sumar(int num){ s = s + num; } synchronized void icalls(){ calls++; } synchronized boolean verificar(int d) { if (d == calls) return true; return false; } }

Figura 5. Clase Acumulador.

ma impl cita la exclusi on mutua en cada una de las operaciones, es decir, sumar al acumulador (a.sumar(numero)) e incrementar la variable calls (a.icalls()). N otese que justo antes de terminar el c odigo del hilo se usa la funci on notify() (ver gura 6) para avisarle a otro hilo (en este caso Principal) que se ha realizado la suma y se ha incrementado el valor de la variable de clase calls.
class Hilo extends Thread{ Acumulador a; int numero; Hilo(Acumulador acc, String id, int f){ super(id); // Nombre para la super clase a = acc; numero = f; } public void run(){ try{ a.sumar(numero); a.icalls(); notify(); }catch(Exception e){} } }

Figura 6. Clase Hilo.

Seg un ya se anticip o, la clase Principal (ver gura 7) se torna en el hilo responsable de imprimir el resultado de la suma, despu es de esperar que los otros N hilos hayan nalizado su trabajo (sumar al acumulador un componente del vector). Inicialmente el hilo Principal se suspende cuando ejecuta la funci on wait(), despu es de determinar que a un el contenido de la variable calls es diferente de N. Cuando alguno de los hilos sumadores ejecuta la funci on

class Principal extends Thread{ Acumulador a; int Done; Principal(Acumulador acc, int d, String id){ super(id); a = acc; Done = d; } public void run(){ while(!a.verificar(Done)){ try{ wait(); }catch(Exception e){} } System.out.println("El total es " + a.s); } }

Seg un se aprecia en este ejemplo, una de las ventajas del c odigo en Java es que es m as coherente al momento de ser interpretado, a diferencia del c odigo en lenguaje C, que a pesar de ser mucho m as compacto es m as dif cil de leer, comprender y depurar. Tambi en inuye el hecho que la sintaxis de las funciones de la biblioteca Pthreads no se presenta amigable al programador novel que se inicia en el campo de la programaci on multihilo.

Figura 7. Clase Principal.

4.
notify()(ver gura 6), el hilo (Principal p) despierta y re-eval ua la condici on de nalizaci on, es decir si calls es diferente de N. Cuando la condici on se eval ua como falsa, entonces se imprime el valor acumulado en la variable de clase s.
class SumaParalela{ public static void main(String args[]){ // Inicializaci on de variables Acumulador acc = new Acumulador(); // Inicializa vector de N componentes Principal p = new Principal(acc, N,"Hilo Principal"); p.start(); for(i=0; i<N; i++){ new Hilo(acc, " Hilo " + (i+1), v[i]).start(); } } }

Conclusiones

Figura 8. Clase SumaParalela.

ltima clase (ver gura 8) deLa cuarta y u nominada SumaParalela, es la encargada de generar (aleatoriamente) el vector de N componentes, adem as de crear los objetos de clase Acumulador, Hilo y Principal, responsables de efectuar la suma paralela. Mediante un lazo for se crean N objetos de clase Hilo; cada uno de ellos ser a responsable de sumar una componente del vector al acumulador s. N otese que el c odigo de la clase Principal puede estar incluido en esta clase (SumaParalela) y de esta forma pudiera evitarse la creaci on de un hilo adicional.

Una vez culminado el presente trabajo, se puede concluir que las dos interfaces estudiadas son apropiadas, siempre y cuando se utilicen para obtener su m aximo provecho. La interfaz Pthreads de C, nos permite obtener muy buenos tiempos de ejecuci on pero con un alto costo de desarrollo; el programador debe conocer el problema con mucho detalle y debe invertir mucho tiempo en la revisi on del c odigo multihilo, ya que el compilador da muy poca ayuda en la b usqueda de errores. Java por su parte permite obtener una r apida soluci on, pero con un alto consumo de recursos de c omputo. Si se quiere mejorar la primera soluci on, se debe gastar gran cantidad de tiempo para su optimizaci on. Java maneja mejor los problemas con alta complejidad, mientras que C se hace m as proclive a errores cuando aumenta la complejidad. En resumen, tomando las palabras de [5], la interfaz de Java se puede comparar con aquel carro autom atico, en el cual se necesita saber poco para poder conducirlo. En contraste, la interfaz Pthreads de C luce como aquel carro sincr onico que permite al conductor experto, sacar el mayor provecho del veh culo cuando llegan las cuestas pronunciadas u obtener la mejor arrancada. La interfaz Pthreads es m as exible, permite obtener un mejor desempe no, pero su utilizaci on resulta compleja. El alto nivel y la exibilidad reducida, permite a Java tener ventaja cuando se desea intentar llevar el problema a otra plataforma u otra arquitectura, ya que la m aquina virtual de Java se encarga de resolver el problema. Por su parte la

interfaz Pthreads, al ser de m as bajo nivel, requiere que el programador haga modicaciones en el c odigo y/o la compilaci on para mantener un buen desempe no de la aplicaci on al cambiar de plataforma o sistema operativo. Como conclusiones particulares se deben resaltar las siguientes: Los tiempos de ejecuci on para los programas elaborados en Pthreads y Java (caso agente viajero)[?], permitieron constatar que C no fue tan r apido (3 o m as veces) como se proclama en varios sitios de la Internet[7], [15], [10]. Por su lado, Java, hasta el momento, no parece ser m as rapido que C, aunque en las nuevas versiones de Java se prometen mejoras en los tiempos de ejecuci on de programas multihilos[9]. Cuando se usa Pthreads es m as f acil sincronizar utilizando sem aforos[3], pero con el uso de los mutex se pueden obtener mejores tiempos de ejecuci on. Esta condici on se veric o cuando se implement o el programa del agente viajero usando sem aforos en lugar de mutex[3] y se midi o que el tiempo de ejecuci on con sem aforos era mayor (1.01 veces) que en las versiones implementadas con sem aforos. Cuando se elaboran programas multihilos, se deben repetir las pruebas innidad de veces para prever cualquiera condici on de carrera que pudiera alterar el resultado nal bajo condiciones excepcionales. Estas condiciones excepcionales se descubren despu es de m ultiples corridas del programa con diferentes juegos de datos de entrada. Esto se constat o en las primeras versiones del programa de la suma paralela, las cuales aparentemente funcionaban bien en las primeras corridas y mostraban errores despu es de realizar varias pruebas.

Prentice-Hall International, 1990. [2] Peter Chapin. Pthread Tutorial. 2002. Tambi en disponible como http://www.ecet.vtc.edu/ pchapin/ pthreadTutorial.pdf. [3] Jorge A. Castellanos D. Estudio comparativo de la interfaz Pthreads del lenguaje de programaci on C y el soporte para programaci on multihilo de Java. Universidad de Carabobo. Facultad Experimental de Ciencias y Tecnolog a. Departamento de Computaci on. Trabajo de Ascenso, 2003. [4] Ren e Dorta F. Implementaci on de la interfaz para programaci on paralela de Modula3 bajo el sistema operativo Mach. Universidad de Carabobo. Escuela de Ingenier a El ectrica. Trabajo de Ascenso, 1998. [5] Edward Fowlkes and Takashi Shida. Multithreaded programming. 1996. http://userpages.umbc.edu/schmitt/331F96 /tshida1/thread.html. [6] A. Silberschatz; J. Peterson; P. Galvin. Sistemas Operativos - Conceptos Fundamentales. Tercera Edici on. Addison-Wesley Iberoamericana, 1994. [7] Eric Galyon. C++ vs Java Performance. Colorado State University, Computer Science Deparment, 1998. Tambi en disponible como http://www.cs.colostate.edu/ cs154/PerfComp/. [8] Ruben Pinilla; Marisa Gil. Jvm: plataform independent vs. performance dependent. Operating Systems Review ACM press, 37(2):4455, April 2003. [9] JAVAOLYMPUS. Java Performance. 2003. Tambi en disponible como http://www.javaolympus.com/java/ PerformanceDirectory.html. [10] Richard P. Martin. C and C++ are being replaced for many applications, but they would never become completely obsolete.

Referencias
[1] Mordechai (Moti) Ben-Ari. Principles of Concurrent and Distributed Programming.

Rutgers University - Computer Science Deparment, 2003. Tambi en disponible como http://www.cs.rutgers.edu/ rmartin/teaching/ spring03/cs553/papers01/04.pdf. [11] Patrick Naughton; Michael Morrison. The Java Handbook. Osborne/McGraw-Hill, 1996. [12] Herbert Shildt. Java2 Manual de Referencia. 4ta. Edici on. McGraw-Hill de Espa na, 2001. [13] William Stallings. Sistemas Operativos Segunda edici on. Prentice Hall, Madrid, 1997. [14] Andrew S. Tanenbaum. Sistemas Operativos Modernos. Primera Edici on. Prentice Hall Hispanoamericana S. A., 1993. [15] Alavoor Vasudevan. C++ Programming HOW-TO. Rootshell Security - Unix Systems security resources, 2000. Tambi en disponible como http://beatbox.suidzer0.org/ docs/c++programming/C++ProgrammingHOWTO.html#toc1.