Threads de Control

La clase ThreadGroup maneja grupos de threads para las aplicaciones Java. Un ThreadGroup puede contener cualquier n�mero de threads. Los threads de un grupo generalmente est�n relacionados de alguna forma, como por qui�n fueron creados, qu� funci�n realizan o cu�ndo deben arrancar o parar.

Un threadGroup no s�lo puede contener threads, tambi�n puede contener otros ThreadGroups. El grupo principal en una aplicaci�n Java es el grupo de threads llamado "main".

Se pueden crear threads y grupos de threads dentro del grupo "main". Tambi�n se pueden crear threads y grupos de threads dentro de subgrupos de "main" y as� sucesivamente.Esto resulta en una herencia del tipo raiz de los threads y los grupos de threads.

La clase ThreadGroup tiene m�todos que pueden ser categorizados de la siguiente forma.

.�M�todos de Manejo de la Colecci�n

El ThreadGroup proporciona un juego de m�todos que maneja los threads y los subgrupos dentro de un grupo y permite que otros objetos le pregunten a ThreadGroup sobre su contenido. Por ejemplo, se puede llamar al m�todo activeCount() para encontrar el n�mero de threads activos actualmente dentro del grupo. Este m�todo se utiliza frecuentemente con el m�todo enumerate() para obtener un array con las referencias de todos los threads activos en el ThreadGroup. Por ejemplo, el m�todo listCurrentThreads() del siguiente ejemplo rellena un array con todos los threads activos en el grupo actual e impime sus nombres.

class EnumerateTest {
    void listCurrentThreads() {
        ThreadGroup currentGroup = Thread.currentThread().getThreadGroup();
        int numThreads;
        Thread[] listOfThreads;

        numThreads = currentGroup.activeCount();
        listOfThreads = new Thread[numThreads];
        currentGroup.enumerate(listOfThreads);
        for (int i = 0; i < numThreads; i++) {
            System.out.println("Thread #" + i + " = " + listOfThreads[i].getName());
        }
    }
}

Otros m�todos de manejo de la colecci�n proporcionados por la clase ThreadGroup incluyen activeGroupCount() y list().

.�M�todos que Operan sobre el Grupo

La clase ThreadGroup soporta varios atributos que son seleccionados y recuperados para el grupo en su totalidad. Estos atributos incluyen la prioridad m�xima que un thread puede tener dentro del grupo, si el grupo es un grupo "daemon", el nombre del grupo, y el nombre del padre del grupo.

Los m�todos que seleccionan y obtienen estos atributos operan a nivel de grupo. Esto es, pueden inspeccionar el atributo del objeto ThreadGroup, pero no afectan a los threads que hay dentro del grupo.

El siguiente listado muestra los m�todos de ThreadGropup que operan a nivel de grupo.

  • getMaxPriority(), y setMaxPriority()
  • getDaemon(), y setDaemon()
  • getName()
  • getParent(), y parentOf()
  • toString()

As�, por ejemplo, cuando se utiliza setMaxPriority() para cambiar la prioridad m�xima del grupo, s�lo est� cambiando el atributo en el grupo, no est� cambiando la prioridad de ninguno de los thread del grupo. Consideremos este peque�o programa que crea un grupo y un thread dentro de �l.

class MaxPriorityTest {
    public static void main(String[] args) {

        ThreadGroup groupNORM = new ThreadGroup(
                                "Un grupo con prioridad normal");
        Thread priorityMAX = new Thread(groupNORM, 
                                "Un thread con prioridad m�xima");

    // Selecciona la prioridad del thread al m�ximo (10)
        priorityMAX.setPriority(Thread.MAX_PRIORITY);

    // Selecciona la prioridad del grupo a normal (5)
        groupNORM.setMaxPriority(Thread.NORM_PRIORITY);

        System.out.println("M�xima prioridad del grupo = " +
                groupNORM.getMaxPriority());
        System.out.println("Prioridad del Thread = " +
                priorityMAX.getPriority());
    }
}

Cuando se crea el grupo groupNORM hereda su atributo de prioridad m�xima desde su grupo padre. En este caso, la prioridad del grupo padre es la m�xima (MAX_PRIORITY) permitida por el sistema de ejecui�n de Java. Luego el programa selecciona la prioridad del thread priorityMAX al m�ximo permitido por el sistema Java. Luego el programa baja la prioridad del grupo a normal (NORM_PRIORITY). El m�todo setMaxPriority() no afecta a la prioridad del thread priorityMAX, por eso en este punto, el thread priorityMAX tienen un prioridad de 10 que es mayor que la prioridad m�xima de su grupo groupNORM. Esta es la salida del programa.

Prioridad m�xima del Grupo = 5
Prioridad del Thread = 10

Como puedes ver un thread puede tener una prioridad superior que el m�ximo permitido por su grupo siempre que la prioridad del thread se haya seleccionado antes de haber bajado la prioridad m�xima del grupo. La prioridad m�xima de un grupo de threads se utiliza para limitar la prioridad de los threads cuando son creados dentro de un grupo o cuando se utiliza setPriority() para cambiar la prioridad del thread. Observa que setMaxPriority() tambi�n cambia la prioridad m�xima de todos sus subgrupos.

Sin embargo, el estado daemon de un grupo s�lo se aplica al grupo. Cambiar el estado daemon de un grupo no afecta al estado daemon de los threads que hay dentro del grupo. Adem�s, el estado daemon de un grupo no implica de ninguna forma el estado daemon de sus treads -- se puede poner cualquier thread dentro de un grupo de threads daemon. El daemon de un grupo de threads s�lo implica que el grupo puede ser destruido cuando todos los threads se han terminado.

.�M�todos que Operan con Todos los Threads de un Grupo.

La clase ThreadGroup tiene tres m�todos que le permiten modificar el estado actual de todos los threads de un grupo.

  • resume()
  • stop()
  • suspend()

Estos m�todos aplican el cambio de estado apropiado a todos los threads del grupo y sus subgrupos.

.�M�todos de Restricci�n de Acceso

La clase ThreadGroup por si misma no impone ninguna restricci�n de acceso, como permitir que los threads de un grupo puedan inspeccionar o medificar threads de un grupo diferente. Mas bien las clases Thread y ThreadGroup cooperan con los manejadores de seguridad (subclases de la clase java.lang.SecurityManager), que puede imponer restricciones de acceso bas�ndose en los miembros de un grupo de threads.

Las clases Thread y threadGroup tienen un m�todo, checkAccess(), que llama al m�todo checkAccess() del controlador de seguridad actual. El controlador de seguridad decide si permite el acceso bas�ndose en los miembros del grupo de threads involucrado.

Si el acceso no est� permitido, el m�todo checkAccess() lanza una excepci�n SecurityException. De otro modo el m�todo checkAccess() simplemente retorna.

La siguiente lista muestra varios m�todos de ThreadGroup que llaman a checkAccess() antes de realizar la acci�n del m�todo. Esto se conoce como acceso regulado, esto es, accesos que deben ser aprobados por el controlador de seguridad antes de poder ser completados.

  • ThreadGroup(ThreadGroup padre, String nombre)
  • setDaemon(boolean isDaemon)
  • setMaxPriority(int maxPriority)
  • stop()
  • suspend()
  • resume()
  • destroy()

Esta es una lista de m�todos de la clase Thread que llaman a checkAccess() antes de proceder.

  • Constructores que especifican un grupo de threads.
  • stop()
  • suspend()
  • resume()
  • setPriority(int priority)
  • setName(String name)
  • setDaemon(boolean isDaemon)

Una aplicaci�n Java solitaria no tiene un controlador de seguridad por defecto. Esto es, por defecto, no se imponen restricciones a ning�n thread para que pueda inspeccionar o modificar cualquier otro thread, sin importar el grupo en el que se encuetra. Se puede definir e implementar propias restricciones de acceso para los grupos de threads mediante la subclasificaci�n de la clase SecurityManager, sobreescribiendo los m�todos apropiados, e instalandolo como el controlador de seguridad para su aplicaci�n.

El navegador HotJava es un ejemplo de aplicaci�n que implementa su propio controlador de seguridad. HotJava necesita asegurarse de que los applets tengan un buen comportamiento y no hagan cosas sucias a otros applets que se est�n ejecutando al mismo tiempo (como bajar la prioridad de otros threads de otros applets). El controlador de seguridad de HotJava no permite que un thread modifique threads de otro grupo. Por favor, observa que las restricciones de acceso basadas en los grupos de threads pueden variar de un navegador a otro y por eso tus applets pueden tener comportamientos diferentes en diferentes navegadores.

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP
ARTÍCULO ANTERIOR

SIGUIENTE ARTÍCULO