MindView Inc.

Pensando em Java, 3ª ed. Revisão 4.0


[ Viewing Hints ] [ Book Home Page ] [ Free Newsletter ]
[ Seminars ] [ Seminars on CD ROM ] [ Consulting ]

Anterior Próximo Página Inicial Índice Conteúdo

13: Concorrência



Objetos fornecem uma maneira de dividir o programa em sessões independêntes. Frequentemente, você também necessita de executar um programa em subtarefas, executando independentemente.



Cada uma destas subtarefas independentes é chamada de thread, e são programadas como se cada thread fosse executada em um CPU diferente. Na realidade um mecanismo divide o tempo de processamento da CPU para você, mas em geral, você não precisa que pensar sobre isto, o que torma muito mais fácil a programação com multiplas threads.Comentários (em inglês)



Um processo é um programa com seu próprio espaço de memória. Um sistema operacional multi-tarefa é capaz de executar mais de um processo(programa) de cada vez, enquanto isto este dá a impressão que cada um esta sozinho, mas períodicamente troca a CPU de uma tarefa para a outra. Uma thread é uma simples sequência de controle de fluxo num processo. Um simples processo pode as vezes ter multiplas threads executando concorrentemente. Comentários (em inglês)



Há vários usos possíveis para multithreading, mas em geral, você tem alguma parte do seu programa ligada a um evento ou recurso particular, e você não quer atrasar o resto do seu programa. Então você cria uma thread associada com aquele evento ou recurso e a deixa rodando independentemente do programa principal.Comentários (em inglês)



Fazer programação concorrente é como entrar em um mundo totalmente novo, e para se aprende uma nova linguagem de programação ou pelo menos todo um novo conjunto de conceitos de programação. Por ter o suporte a threads ficado disponível na maioria dos sistemas operacionais de micros, surgiram extensões para usar threads nas linguagens de programação ou em bibliotecas. Em todos casos, a programação usando threads:

  1. Parece misteriosa e requer uma mudança na forma de se entender a programação
  2. Parece similar ao suporte a threads em outras linguagens. Por isso, quando vc entende o que são threads, você entende uma língua comum


E, embora o suporte a threads possa fazer do Java uma linguagem mais complicada, isto não é totalmente culpa do Java - threads são difíceis. Comentários (em inglês)



Entender o conceito de programação concorrente tem o mesmo grau de dificuldade que entender o polimorfismo. Se você se esforçar, pode chegar a entender o mecanismo básico. Mas em geral leva tempo até se ficar totalmente à vontade com o assunto. O objetivo deste capítulos é oferecer a você bases sólidas dos pontos fundamentais da concorrência, para que você possa entender os conceitos e possa escrever programas que usem threads de modo razoável. Saiba que você pode rapidamente ficar autoconfiante demais. Por isso, se estiver escrevendo algo complexo, vai ter que estudar livros totalmente dedicados assunto. Comentários (em inglês)

Motivação



Uma das razões mais fortes para se usar concorrência é criar uma interface com o usuário que tenha resposta ágil. Considere um programa que faça uma operação que use muita CPU, e que por isso chega a ignorar os comandos do usuário e a deixar de responder. O problema é que o programa precisa continuar a realizar sua operação, ao mesmo tempo ele precisar devolver o controle para a interface com o usuário, para que responder ao usuário. Se o programa tiver um botão de "cancelar", você não vai quer ser forçado a consultar o botão a cada vez que um trecho de código é executado no programa. E contudo, você gostaria que o botão de Cancelar sempre respondesse, como se estivesse consultando-o regularmente.Comentários (em inglês)



Um método convencional não poderia continuar a realizar suas operações e ao mesmo tempo retornar controle para o restante do programa. De fato, isso parece impossível de se conseguir, pois seria como se a CPU pudesse estar em dois lugares ao mesmo tempo. Mas precisamente esta é a ilusão que a concorrência oferece. Comentários (em inglês)



A concorrência também pode ser usada para otimizar a produção, ou throughput. Por exemplo, graças a ela você pode fazer um trabalho importante enquanto está bloqueado esperando a entrada de dados de uma porta de I/O. Sem o uso de threads, a única solução razoável seria tentar ler de tempos em tempos (ou "polar"), o que não é prático e pode ser difícil de se fazer. Comentários (em inglês)



If you have a multiprocessor machine, multiple threads may be distributed across multiple processors, which can dramatically improve throughput. This is often the case with powerful multiprocessor web servers, which can distribute large numbers of user requests across CPUs in a program that allocates one thread per request. Comentários (em inglês)



Não se deve esquecer de que um programa com muitos threads pode também ser executado em uma máquina com uma única CPU. Portanto, pode ser possível escrever o mesmo programa sem usar quaisquer threads. Contudo, o uso de programação com multithreads permite um ganho organizacional muito importante, que permite simplificar muito o projeto de seu programa. Alguns tipos de problemas, como simulações -- por exemplo, um jogo por computador -- são muito dificeis de se escrever sem o suporte à concorrência. Comentários (em inglês)



O modelo de threads facilita a programação, permitindo lidar com várias operações ao mesmo tempo, dentro de um mesmo programa. Com o uso de threads, a CPU vai se dividir e dar a cada thread uma parte de seu tempo. Cada thread tem a impressão de ter a CPU toda para ele, mas o tempo da CPU na verdade é fatiado entre todos os threads. A exceção disto é se seu programa está sendo executado em múltiplas CPUs, mas uma das grandes coisas a respeito de threads é que você pode abstrair este nível. Assim, seu código não precisa saber se ele está sendo rodado em uma ou em várias CPUs. Portanto, os threads são uma forma de se criar programas transparentemente escaláveis -- se um programa estiver rodando muito lentamente, ele pode ser acelerado acrescentando-se mais CPUs a seu computador. O uso de programas multitarefa ou de múltiplos threads tende a ser a forma mais razoável de se programar sistemas multiprocessadores. Comentários (em inglês)



O uso de threads pode reduzir a eficiência de computação em máquinas com uma única CPU. Mas muitas vezes são valiosos os ganhos na melhoria do projeto do programa, no uso mais balanceado de recursos e na maior conveniência para o usuário. Em geral, os threads podem permitir que se crie um projeto com acoplamento menos forte. Caso contrário, partes do código teriam que explicitamente dar atenção a tarefas que normalmente seriam gerenciadas por threads. Comentários (em inglês)

Uso básico de threads



The simplest way to create a thread is to inherit from java.lang.Thread, which has all the wiring necessary to create and run threads. The most important method for Thread is run( ), which you must override to make the thread do your bidding. Thus, run( ) is the code that will be executed “simultaneously” with the other threads in a program. Comentários (em inglês)



O exemplo a seguir cria cinco threads. Cada um deles é identificado por um número distinto, gerado usando-se uma variável estática. O método run( ) do Thread é substituído para decrementar um contador a cada vez que ele passa por seu laço. Ele retorna quando o contador é zero. Quando run( ) retorna, o thread é automaticamente terminado pelos mecanismo de gerência de threads. Comentários (em inglês)



//: c13:SimpleThread.java
// Very simple Threading example.
import com.bruceeckel.simpletest.*;

public class SimpleThread extends Thread {
  private static Test monitor = new Test();
  private int countDown = 5;
  private static int threadCount = 0;
  public SimpleThread() {
    super("" + ++threadCount); // Store the thread name
    start();
  }
  public String toString() {
    return "#" + getName() + ": " + countDown;
  }
  public void run() {
    while(true) {
      System.out.println(this);
      if(--countDown == 0) return;
    }
  }
  public static void main(String[] args) {
    for(int i = 0; i < 5; i++)
      new SimpleThread();
    monitor.expect(new String[] {
      "#1: 5",
      "#2: 5",
      "#3: 5",
      "#5: 5",
      "#1: 4",
      "#4: 5",
      "#2: 4",
      "#3: 4",
      "#5: 4",
      "#1: 3",
      "#4: 4",
      "#2: 3",
      "#3: 3",
      "#5: 3",
      "#1: 2",
      "#4: 3",
      "#2: 2",
      "#3: 2",
      "#5: 2",
      "#1: 1",
      "#4: 2",
      "#2: 1",
      "#3: 1",
      "#5: 1",
      "#4: 1"
    }, Test.IGNORE_ORDER + Test.WAIT);
  }
} ///:~




Os objetos de tipo thread recebem nomes exclusivos chamando-se o construtor Thread apropriado. O nome pode ser consulado em toString( ) usando-se getName( ).



O método run( ) de um Thread virtualmente sempre tem algum tipo de laço (ou loop) que continua até que o thread não seja mais necessário. Assim, você precisa definir as condições para interromper este loop, ou como no programa anterior, simplesmente fazer return no método run( ). Muitas vezes, o run( ) é definido como um laço infinito, o que significa que, a não ser por alguma condição que faça com que run( ) termine, ele será sempre executado -- mais à frente neste capítulo veremos como é possível, de modo seguro, sinalizar um thread para que termine. Comentários (em inglês)



Na função main( ) podem ser vistos vários threads sendo criados e executados. O método start( ) da classe Thread executa inicializações especiais para o thread e então chama run( ). Deste modo, os passos são: o construtor é chamado para se construir o projeto, ele então chama start( ) para configurar o thread e então o mecanismo de execução do thread chama run( ). Se start( ) não for chamada (o que não precisa ser feito no construtor, como será visto nos próximos exemplos), o thread nunca será disparado. Comentários (em inglês)



A saída de uma execução deste programa será diferente de outra, porque o mecanismo de escalonamento de threads não é determinístico. De fato, você vai poder ver diferenças dramáticas entre uma versão e outra do JDK na saída deste exemplo. Por exemplo, um JDK anterior não fatiava o tempo muito frequentemente. Assim, o thread 1 poderia fazer seus loops até o fim, depois o thread 2 faria todos seus loops etc. Isto era praticamente a mesma coisa que chamar uma rotina que faria todos os loops de uma vez só, com a exceção de que o disparo de todos esses threads seria mais custoso. No JDK 1.4 tem-se algo na forma SimpleThread.java, que indica que o escalonador faz um fatiamento melhor do tempo-agora parece que cada thread recebe um serviço regular. Em geral, esses tipos de mudanças de comportamento de cada JDK não são mencionadas pela Sun, e por isso não é possível planejar qualquer comportamento consistente dos threads. A melhor abordagem é ser tão conservador quanto possível no momento de escrever código que usa threads. Comentários (em inglês)



Quando main( ) cria objetos de tipo Thread, ele não captura as referências a nenhum deles. Se eles fossem objetos comuns, isto os tornaria suscetíveis da coleta de lixo. Mas não um Thread. Cada Thread se “registra” e por isto há uma referência a ele em algum lugar. Por isso, o coletor de lixo não pode removê-lo até que o thread termine seu run( ) e desapareça.Comentários (em inglês)

Yielding, ou "ceder"



Quando o que se precisa fazer já foi realizado no métdo run( ) é possível dar uma dica ao mecanismo de escalonamento de threads que seu thread terminou e que algum outro thread pode obter a CPU. Esta dica (e ela é mesmo uma dica, pois não há garantia que sua implementação vai ouvi-la) tem a forma do método yield( ). Comentários (em inglês)



O exemplo anterior pode ser modificado colocando-se yeld depois de cada laço ou loop:



//: c13:YieldingThread.java
// Suggesting when to switch threads with yield().
import com.bruceeckel.simpletest.*;

public class YieldingThread extends Thread {
  private static Test monitor = new Test();
  private int countDown = 5;
  private static int threadCount = 0;
  public YieldingThread() {
    super("" + ++threadCount);
    start();
  }
  public String toString() {
    return "#" + getName() + ": " + countDown;
  }
  public void run() {
    while(true) {
      System.out.println(this);
      if(--countDown == 0) return;
      yield();
    }
  }
  public static void main(String[] args) {
    for(int i = 0; i < 5; i++)
      new YieldingThread();
    monitor.expect(new String[] {
      "#1: 5",
      "#2: 5",
      "#4: 5",
      "#5: 5",
      "#3: 5",
      "#1: 4",
      "#2: 4",
      "#4: 4",
      "#5: 4",
      "#3: 4",
      "#1: 3",
      "#2: 3",
      "#4: 3",
      "#5: 3",
      "#3: 3",
      "#1: 2",
      "#2: 2",
      "#4: 2",
      "#5: 2",
      "#3: 2",
      "#1: 1",
      "#2: 1",
      "#4: 1",
      "#5: 1",
      "#3: 1"
    }, Test.IGNORE_ORDER + Test.WAIT);
  }
} ///:~




Quando se usa yield( ), a saída fica bastante mais equilibrada. Mas observe que se a cadeia de caracteres de saída for mais longa, a saída observada vai ser basicamente a mesma de SimpleThread.java (experimente —altere toString( ) para mostrar cadeias de caracteres cada vez mais longas, para ver o que acontece). Uma vez que o mecanismo de escalonamento é preemptivo, ele decide interromper um thread e chavear para outro quando quer que ele deseje. Por isso, a entrada e saída (que são executados através do thread main( ) ) levam tanto tempo: ele é interrompido antes que o run( ) tenha a chance de ceder o processamento usando yield( ). Em geral, yield( ) é útil apenas em situações muito raras, e não se pode confiar nele para fazer qualquer ajuste mais sério de seus aplicativos. Comentários (em inglês)

Sleeping, ou "dormir"



Outra forma de se controlar o comportamento de um thread é chamando-se sleep( ) para suspender a execução por um dado número de mili-segundos. No exemplo precedente, caso seja substituída a chamada a yield( ) por uma chamada a sleep( ), tem-se: Comentários (em inglês)



//: c13:SleepingThread.java
// Calling sleep() to wait for awhile.
import com.bruceeckel.simpletest.*;

public class SleepingThread extends Thread {
  private static Test monitor = new Test();
  private int countDown = 5;
  private static int threadCount = 0;
  public SleepingThread() {
    super("" + ++threadCount);
    start();
  }
  public String toString() {
    return "#" + getName() + ": " + countDown;
  }
  public void run() {
    while(true) {
      System.out.println(this);
      if(--countDown == 0) return;
      try {
        sleep(100);
      } catch (InterruptedException e) {
        throw new RuntimeException(e);
      }
    }
  }
  public static void
  main(String[] args) throws InterruptedException {
    for(int i = 0; i < 5; i++)
      new SleepingThread().join();
    monitor.expect(new String[] {
      "#1: 5",
      "#1: 4",
      "#1: 3",
      "#1: 2",
      "#1: 1",
      "#2: 5",
      "#2: 4",
      "#2: 3",
      "#2: 2",
      "#2: 1",
      "#3: 5",
      "#3: 4",
      "#3: 3",
      "#3: 2",
      "#3: 1",
      "#4: 5",
      "#4: 4",
      "#4: 3",
      "#4: 2",
      "#4: 1",
      "#5: 5",
      "#5: 4",
      "#5: 3",
      "#5: 2",
      "#5: 1"
    });
  }
} ///:~




Quando se chama sleep( ), deve-se colocá-la dentro de um bloco de try, pois é possível que sleep( ) seja interrompida antes do tempo esperado. Isto acontece sempre que algum trecho de código tem uma referência ao thread e chama interrupt( ) sobre o thread (interrupt( ) também afeta o thread se wait( ) ou join( ) forem chamadas para isso; assim, estas chamadas também devem estar em um bloco try —estes métodos vão ser ensinados mais à frente). De forma geral, se você vai sair de um thread suspenso usando interrupt( ) deve usar wait( ) em vez de sleep( ), para que o término na cláusula catch seja improvável. Aqui, seguimos a máxima “não inttercepte uma exceção, a não ser que você saiba o que fazer com ela": nós a disparamos novamente, como uma RuntimeException. Comentários (em inglês)



Pode-se observar que a saída é determinística-cada thread decrementa seu contador até o fim antes que seja disparado o próximo thread. Isto ocorre porque join( ) (que vamos discutir em breve) é usada em cada thread, o que faz com que main( ) aguarde que o tthread termine antes de continuar. Caso não se use join( ), observa-se que os threads tendem a ser executados em qualquer ordem, o que significa que sleep( ) também não é uma forma de controlar a ordem de execução dos threads. Ela apenas suspende a execução do thread por um certo intervalo de tempo-neste caso 100 milissegundos. A única garantia que se tem é que o thread vai ser suspenso por pelo menos 100 milissegundos. Contudo, vai ser necessário um tempo maior para que o thread volte a ser executado, pois o escalonador de threads tem que reassumir o controle depois de terminado o intervalo de suspensão do thread. Comentários (em inglês)



Caso se queira controlar a ordem de execução dos threads, a melhor idéia é não usar threads, mas sim criar rotinas próprias, cooperativas, que passem o controle entre si em uma ordem especificada.Comentários (em inglês)

Prioridade



The priority of a thread tells the scheduler how important this thread is. Although the order that the CPU attends to an existing set of threads is indeterminate, if there are a number of threads blocked and waiting to be run, the scheduler will lean toward the one with the highest priority first. However, this doesn’t mean that threads with lower priority aren’t run (that is, you can’t get deadlocked because of priorities). Lower priority threads just tend to run less often. Comentários (em inglês)



Na listagem a seguir, o programa SimpleThread.java foi modificado para mostrar os diferentes níveis de prioridade. As prioridades são ajustadas usando-se o método setPriority( ) da classe Thread.



//: c13:SimplePriorities.java
// Shows the use of thread priorities.
import com.bruceeckel.simpletest.*;

public class SimplePriorities extends Thread {
  private static Test monitor = new Test();
  private int countDown = 5;
  private volatile double d = 0; // No optimization
  public SimplePriorities(int priority) {
    setPriority(priority);
    start();
  }
  public String toString() {
    return super.toString() + ": " + countDown;
  }
  public void run() {
    while(true) {
      // An expensive, interruptable operation:
      for(int i = 1; i < 100000; i++)
        d = d + (Math.PI + Math.E) / (double)i;
      System.out.println(this);
      if(--countDown == 0) return;
    }
  }
  public static void main(String[] args) {
    new SimplePriorities(Thread.MAX_PRIORITY);
    for(int i = 0; i < 5; i++)
      new SimplePriorities(Thread.MIN_PRIORITY);
    monitor.expect(new String[] {
      "Thread[Thread-1,10,main]: 5",
      "Thread[Thread-1,10,main]: 4",
      "Thread[Thread-1,10,main]: 3",
      "Thread[Thread-1,10,main]: 2",
      "Thread[Thread-1,10,main]: 1",
      "Thread[Thread-2,1,main]: 5",
      "Thread[Thread-2,1,main]: 4",
      "Thread[Thread-2,1,main]: 3",
      "Thread[Thread-2,1,main]: 2",
      "Thread[Thread-2,1,main]: 1",
      "Thread[Thread-3,1,main]: 5",
      "Thread[Thread-4,1,main]: 5",
      "Thread[Thread-5,1,main]: 5",
      "Thread[Thread-6,1,main]: 5",
      "Thread[Thread-3,1,main]: 4",
      "Thread[Thread-4,1,main]: 4",
      "Thread[Thread-5,1,main]: 4",
      "Thread[Thread-6,1,main]: 4",
      "Thread[Thread-3,1,main]: 3",
      "Thread[Thread-4,1,main]: 3",
      "Thread[Thread-5,1,main]: 3",
      "Thread[Thread-6,1,main]: 3",
      "Thread[Thread-3,1,main]: 2",
      "Thread[Thread-4,1,main]: 2",
      "Thread[Thread-5,1,main]: 2",
      "Thread[Thread-6,1,main]: 2",
      "Thread[Thread-4,1,main]: 1",
      "Thread[Thread-3,1,main]: 1",
      "Thread[Thread-6,1,main]: 1",
      "Thread[Thread-5,1,main]: 1"
    }, Test.IGNORE_ORDER + Test.WAIT);
  }
} ///:~




Nesta versão, toString( ) é substituída pelo uso de Thread.toString( ), que imprime o nome do thread (que pode ser definido através do construtor; aqui ele é automaticamente gerado como Thread-1, Thread-2 etc.), o nível de prioridade e o “grupo de threads” ao qual o thread pertence. Como os threads se auto-identificam, não há threadNumber neste exemplo. O métodotoString( ) que substitui o original também mostra o valor do contador decrescente do thread.Comentários (em inglês)



Pode-se ver que para threads o nível de prioridade 1 é o mais alto, e que todos os outros threads estão no nível de prioridade mais baixo.Comentários (em inglês)



Em run( ) foram acrescentadas 100.000 repetições de um cálculo muito pesado, que envolve adição e divisão de valores de tipo double. A variável d foi declarada volatile para garantir que não seja efetuada nenhuma otimização. Sem estes cálculos não se poderia ver o efeito de se definirem os níveis de prioridade. (Experimente: comente o laço for contendo os cálculos com valores de tipo double.) Com os cálculos, pode-se ver que o thread 1 recebe preferência maior do escalonador de threads -- pelo menos este foi comportamento em minha máquina Windows 2000. Apesar de escrever na tela ser também uma operação cara, não é possível ver os níveis de prioridade usando-a, pois a impressão na tela não é interrompida (caso contrário os textos na console ficariam misturados devido ao uso de threads), ao passo que os cálculos matemáticos podem ser interrompidos. Os cálculos levam um tempo suficiente para que o mecanismo de escalonamento de threads possa atuar e chavear os threads, levando em conta suas prioridades, o que faz com que o thread 1 tenha a preferência.Comentários (em inglês)



A prioridade de um thread já existente pode ser lida por getPriority( ) e também pode ser alterada a qualquer momento (não apenas no construtor, como em SimplePriorities.java) porsetPriority( ).



Apesar de haver 10 níveis de prioridade no JDK, eles nem sempre estão disponíveis em muitos sistemas operacionais. Por exemplo, em Windows 2000 há sete níveis de prioridade, por isso o mapeamento é indefinido -- apesar de que o Solaris da Sun tem 231 níveis). A única abordagem portável é usar apenas MAX_PRIORITY, NORM_PRIORITY e MIN_PRIORITY quando se definem níveis de prioridade. Comentários (em inglês)

Threads daemon



Um thread “daemon” tem a função de oferecer um serviço geral no background, porquanto seu programa esteja executando, mas não é parte da essência do programa. Assim, quando todos threads que não sejam daemon terminam, o programa é terminado. Reciprocamente, se há qualquer thread não daemon em execução, o programa não termina. Por exemplo, main( )é executado por um thread não daemon.Comentários (em inglês)



//: c13:SimpleDaemons.java
// Daemon threads don't prevent the program from ending.

public class SimpleDaemons extends Thread {
  public SimpleDaemons() {
    setDaemon(true); // Must be called before start()
    start();
  }
  public void run() {
    while(true) {
      try {
        sleep(100);
      } catch (InterruptedException e) {
        throw new RuntimeException(e);
      }
      System.out.println(this);
    }
  }
  public static void main(String[] args) {
    for(int i = 0; i < 10; i++)
      new SimpleDaemons();
  }
} ///:~




Para fazer com que um thread se torne um daemon, deve-se chamar setDaemon( ) antes de dispará-lo. Em run( ), o thread é colocado em suspensão por alguns momentos. Depois que todos threads foram disparados, o programa termina imediatamente, antes que qualquer thread possa escrever na tela. Isto ocorre porque (com a exceção de main( )) não há threads não daemon mantendo o programa aberto. Assim, o programa termina sem gerar qualquer saída.



Pode-se determinar se um thread é daemon ou não por uma chamada a isDaemon( ). Se um thread for um daemon, quaisquer threads que ele criar serão automaticamente também daemons, como mostra o exemplo a seguir: Comentários (em inglês)



//: c13:Daemons.java
// Daemon threads spawn other daemon threads.
import java.io.*;
import com.bruceeckel.simpletest.*;

class Daemon extends Thread {
  private Thread[] t = new Thread[10];
  public Daemon() {
    setDaemon(true);
    start();
  }
  public void run() {
    for(int i = 0; i < t.length; i++)
      t[i] = new DaemonSpawn(i);
    for(int i = 0; i < t.length; i++)
      System.out.println("t[" + i + "].isDaemon() = "
        + t[i].isDaemon());
    while(true)
      yield();
  }
}

class DaemonSpawn extends Thread {
  public DaemonSpawn(int i) {
    start();
    System.out.println("DaemonSpawn " + i + " started");
  }
  public void run() {
    while(true)
      yield();
  }
}

public class Daemons {
  private static Test monitor = new Test();
  public static void main(String[] args) throws Exception {
    Thread d = new Daemon();
    System.out.println("d.isDaemon() = " + d.isDaemon());
    // Allow the daemon threads to
    // finish their startup processes:
    Thread.sleep(1000);
    monitor.expect(new String[] {
      "d.isDaemon() = true",
      "DaemonSpawn 0 started",
      "DaemonSpawn 1 started",
      "DaemonSpawn 2 started",
      "DaemonSpawn 3 started",
      "DaemonSpawn 4 started",
      "DaemonSpawn 5 started",
      "DaemonSpawn 6 started",
      "DaemonSpawn 7 started",
      "DaemonSpawn 8 started",
      "DaemonSpawn 9 started",
      "t[0].isDaemon() = true",
      "t[1].isDaemon() = true",
      "t[2].isDaemon() = true",
      "t[3].isDaemon() = true",
      "t[4].isDaemon() = true",
      "t[5].isDaemon() = true",
      "t[6].isDaemon() = true",
      "t[7].isDaemon() = true",
      "t[8].isDaemon() = true",
      "t[9].isDaemon() = true"
    }, Test.IGNORE_ORDER + Test.WAIT);
  }
} ///:~




O thread Daemon define sua flag daemon thread como “true” e então dispara vários outros threads—que nãose atribuem o modo daemon-para mostrar que eles são daemons de qualquer modo. A seguir ele entra em um laço infinito que chama yield( ) para transferir o controle para os outros processos. Comentários (em inglês)



Não há nada que impeça o programa de terminar depois que main( ) termina seu trabalho, uma vez que apenas threads do tipo daemon estão sendo executados. Para que seja possível ver o resultado de disparar todos os threads daemon, o thread de main( ) é mantido suspenso por um segundo. Sem isso, pode-se ver apenas parte dos resultados da criação dos threads daemon. (Tente fazer chamadas a sleep( ) de vários tamanhos de intervalo de suspensão para ver esse resultado.) Comentários (em inglês)

Unir a um thread



Um thread pode chamar join( ) sobre um outro thread para aguardar que o segundo thread termine antes de continuar. Se um thread chamar t.join( ) sobre outro thread t, então o thread que chamar fica suspenso até que o thread alvo t termine (o que ocorre quandot.isAlive( ) forfalse).



Também é possível chamar join( ) com um argumento de timeout (em milissegundos, ou então em milissegundos e nanossegundos), para que, se o segundo thread não terminar nesse período de tempo, a chamada a join( ) termine de qualquer forma.



A chamada a join( ) pode ser abortada chamando-se interrupt( ) sobre o thread que a chama. Por isso, é preciso usar um bloco de try-catch.



All of these operations are shown in the following example:



//: c13:Joining.java
// Understanding join().
import com.bruceeckel.simpletest.*;

class Sleeper extends Thread {
  private int duration;
  public Sleeper(String name, int sleepTime) {
    super(name);
    duration = sleepTime;
    start();
  }
  public void run() {
    try {
      sleep(duration);
    } catch (InterruptedException e) {
      System.out.println(getName() + " was interrupted. " +
        "isInterrupted(): " + isInterrupted());
      return;
    }
    System.out.println(getName() + " has awakened");
  }
}

class Joiner extends Thread {
  private Sleeper sleeper;
  public Joiner(String name, Sleeper sleeper) {
    super(name);
    this.sleeper = sleeper;
    start();
  }
  public void run() {
   try {
      sleeper.join();
    } catch (InterruptedException e) {
      throw new RuntimeException(e);
    }
    System.out.println(getName() + " join completed");
  }
}

public class Joining {
  private static Test monitor = new Test();
  public static void main(String[] args) {
    Sleeper
      sleepy = new Sleeper("Sleepy", 1500),
      grumpy = new Sleeper("Grumpy", 1500);
    Joiner
      dopey = new Joiner("Dopey", sleepy),
      doc = new Joiner("Doc", grumpy);
    grumpy.interrupt();
    monitor.expect(new String[] {
      "Grumpy was interrupted. isInterrupted(): false",
      "Doc join completed",
      "Sleepy has awakened",
      "Dopey join completed"
    }, Test.AT_LEAST + Test.WAIT);
  }
} ///:~




A Um Sleeper é um tipo de Thread que fica suspenso por um período de tempo especificado no construtor. Em run( ), a chamada para sleep( ) pode terminar quando esse período de tempo expira, mas ela também pode ser interrompida. Dentro da cláusula catch, a interrupção é informada, junto com o valor de isInterrupted( ). Quando outro thread chama interrupt( ) sobre este thread, é setada uma flag que indica que o thread foi interrompido. Contudo, este flag é apagado quando a exceção é recebida, para que o resultado sempre seja falso dentro da cláusula catch. A flag é usada para outras situações nas quais um thread pode examinar seu estado interrompido fora da exceção.



Um Joiner é um thread que aguarda que um Sleeper acorde chamando join( ) sobre o objeto Sleeper. Em main( ), cada Sleeper tem um Joiner. É possível ver pela saída se o Sleeper é interrompido ou termina normalmente, e também que o Joiner termina juntamente com o Sleeper.

Variações de codificação



Nos exemplos simples vistos até aqui, os objetos de tipo thread são todos herdados de Thread. Isto faz sentido porque os objetos são claramente sendo criados apenas como threads, e não tem nenhum outro comportamento. Contudo, sua classe pode já ter sido herdada de outra classe. Neste caso, não se pode herdar de Thread, pois Java não permite herança múltipla. Neste caso, pode-se usar a abordagem alternativa de implementar a interface Runnable, ou "executável". Runnable especifica apenas que será implementado um método run( ), e Thread também implementa Runnable. Comentários (em inglês)



This example demonstrates the basics:



//: c13:RunnableThread.java
// SimpleThread using the Runnable interface.

public class RunnableThread implements Runnable {
  private int countDown = 5;
  public String toString() {
    return "#" + Thread.currentThread().getName() +
      ": " + countDown;
  }
  public void run() {
    while(true) {
      System.out.println(this);
      if(--countDown == 0) return;
    }
  }
  public static void main(String[] args) {
    for(int i = 1; i <= 5; i++)
      new Thread(new RunnableThread(), "" + i).start();
    // Output is like SimpleThread.java
  }
} ///:~




A única coisa de que uma classe Runnable precisa é um método run( ), mas para fazer qualquer outra coisa com um objeto thread Thread (como getName( ) em toString( )), deve-se obter uma referência explícita a ele através de uma chamada a Thread.currentThread( ). Esse construtor de Thread usa um objeto de tipoRunnable e um nome para o thread.



When something has a Runnable interface, it simply means that it has a run( ) method, but there’s nothing special about that—it doesn’t produce any innate threading abilities, like those of a class inherited from Thread. So to produce a thread from a Runnable object, you must create a separate Thread object as shown in this example, handing the Runnable object to the special Thread constructor. You can then call start( ) for that thread, which performs the usual initialization and then calls run( ). Comentários (em inglês)



O que é conveniente na interface Runnable é que tudo pertence à mesma classe. Isto é: Runnable permite um mixin, ou mistura, de uma classe base e de outra interface. Se você precisar alguma coisa, pode fazê-lo diretamente, sem passar por um objeto distinto. Contudo, as classes internas têm o mesmo acesso fácil a todas as partes de uma classe externa. Por isso, o acesso a membros não é uma razão forte para usar Runnable como um mixin, em vez de como uma subclasse interna de Thread. Comentários (em inglês)



Quando se usa Runnable, em geral se tem a intenção de criar um processo em um trecho de código—implementado como o método run( )-em vez de um objeto representando o processo. Isto é tema de debates, dependendo do que pareça fazer mais sentido: representar um thread como um objeto ou como uma entidade completamente diferente, um processo [68]. Caso se decida pensar nele como um processo, fica-se livre do mandamento da orientação ao objeto: “tudo é um objeto”. Isto também significa que não há razão para tornar toda a classe Runnable se tudo o que se deseja é iniciar um processo para controlar parte de um programa. Devido a isso, faz mais sentido esconder a parte do programa que faz uso de threads dentro de uma classe interna, como mostrado aqui:



//: c13:ThreadVariations.java
// Creating threads with inner classes.
import com.bruceeckel.simpletest.*;

// Using a named inner class:
class InnerThread1 {
  private int countDown = 5;
  private Inner inner;
  private class Inner extends Thread {
    Inner(String name) {
      super(name);
      start();
    }
    public void run() {
      while(true) {
        System.out.println(this);
        if(--countDown == 0) return;
        try {
          sleep(10);
        } catch (InterruptedException e) {
          throw new RuntimeException(e);
        }
      }
    }
    public String toString() {
      return getName() + ": " + countDown;
    }
  }
  public InnerThread1(String name) {
    inner = new Inner(name);
  }
}

// Using an anonymous inner class:
class InnerThread2 {
  private int countDown = 5;
  private Thread t;
  public InnerThread2(String name) {
    t = new Thread(name) {
      public void run() {
        while(true) {
          System.out.println(this);
          if(--countDown == 0) return;
          try {
            sleep(10);
          } catch (InterruptedException e) {
            throw new RuntimeException(e);
          }
        }
      }
      public String toString() {
        return getName() + ": " + countDown;
      }
    };
    t.start();
  }
}

// Using a named Runnable implementation:
class InnerRunnable1 {
  private int countDown = 5;
  private Inner inner;
  private class Inner implements Runnable {
    Thread t;
    Inner(String name) {
      t = new Thread(this, name);
      t.start();
    }
    public void run() {
      while(true) {
        System.out.println(this);
        if(--countDown == 0) return;
        try {
          Thread.sleep(10);
        } catch (InterruptedException e) {
          throw new RuntimeException(e);
        }
      }
    }
    public String toString() {
      return t.getName() + ": " + countDown;
    }
  }
  public InnerRunnable1(String name) {
    inner = new Inner(name);
  }
}

// Using an anonymous Runnable implementation:
class InnerRunnable2 {
  private int countDown = 5;
  private Thread t;
  public InnerRunnable2(String name) {
    t = new Thread(new Runnable() {
      public void run() {
        while(true) {
          System.out.println(this);
          if(--countDown == 0) return;
          try {
            Thread.sleep(10);
          } catch (InterruptedException e) {
            throw new RuntimeException(e);
          }
        }
      }
      public String toString() {
        return Thread.currentThread().getName() +
          ": " + countDown;
      }
    }, name);
    t.start();
  }
}

// A separate method to run some code as a thread:
class ThreadMethod {
  private int countDown = 5;
  private Thread t;
  private String name;
  public ThreadMethod(String name) { this.name = name; }
  public void runThread() {
    if(t == null) {
      t = new Thread(name) {
        public void run() {
          while(true) {
            System.out.println(this);
            if(--countDown == 0) return;
            try {
              sleep(10);
            } catch (InterruptedException e) {
              throw new RuntimeException(e);
            }
          }
        }
        public String toString() {
          return getName() + ": " + countDown;
        }
      };
      t.start();
    }
  }
}

public class ThreadVariations {
  private static Test monitor = new Test();
  public static void main(String[] args) {
    new InnerThread1("InnerThread1");
    new InnerThread2("InnerThread2");
    new InnerRunnable1("InnerRunnable1");
    new InnerRunnable2("InnerRunnable2");
    new ThreadMethod("ThreadMethod").runThread();
    monitor.expect(new String[] {
      "InnerThread1: 5",
      "InnerThread2: 5",
      "InnerThread2: 4",
      "InnerRunnable1: 5",
      "InnerThread1: 4",
      "InnerRunnable2: 5",
      "ThreadMethod: 5",
      "InnerRunnable1: 4",
      "InnerThread2: 3",
      "InnerRunnable2: 4",
      "ThreadMethod: 4",
      "InnerThread1: 3",
      "InnerRunnable1: 3",
      "ThreadMethod: 3",
      "InnerThread1: 2",
      "InnerThread2: 2",
      "InnerRunnable2: 3",
      "InnerThread2: 1",
      "InnerRunnable2: 2",
      "InnerRunnable1: 2",
      "ThreadMethod: 2",
      "InnerThread1: 1",
      "InnerRunnable1: 1",
      "InnerRunnable2: 1",
      "ThreadMethod: 1"
    }, Test.IGNORE_ORDER + Test.WAIT);
  }
} ///:~




InnerThread1 creates a named inner class that extends Thread, and makes an instance of this inner class inside the constructor. This makes sense if the inner class has special capabilities (new methods) that you need to access in other methods. However, most of the time the reason for creating a thread is only to use the Thread capabilities, so it’s not necessary to create a named inner class. InnerThread2 shows the alternative: An anonymous inner subclass of Thread is created inside the constructor and is upcast to a Thread reference t. If other methods of the class need to access t, they can do so through the Thread interface, and they don’t need to know the exact type of the object.



A terceira e a quarta classes deste exemplo repetem a primeira e a segunda, mas usam a interface Runnable em vez da classe Thread. Isto foi feito apenas para mostrar que Runnable não tem vantagem nenhuma nesta situação, mas que de fato é um pouco mais complicada de codificar (e de se ler o código). Por isso, minha inclinação é usar Thread a não ser que eu seja de alguma forma forçado a usar Runnable.



A classe ThreadMethod mostra a criação de um thread dentro de um método. O método é chamado quando se está pronto para executar o thread, e ele retorna depois que o thread começa. Se o thread estiver apenas realizando uma operação auxiliar, em vez de ser fundamental para a classe, esta é provavelmente a abordagem mais útil e apropriada, em vez de se iniciar um thread dentro do construtor da classe.

Criação de interfaces com o usuário que sejam responsivas



Conforme comentado antes, uma das motivações para usar threads é criar uma interface com o usuário "responsiva", ou que dê respostas em tempo hábil. Não vamos ver interfaces gráficas com o usuário até o Capítulo 14; por isso vamos apresentar aqui um exemplo simples de uma interface com o usuário baseada em console. O exemplo tem duas versões: uma que fica totalmente ocupada durante os cálculos, e por isso não pode ler a entrada da console, e outra que coloca os cálculos dentro de um thread e por isso pode fazer os cálculos e também esperar a entrada de dados pela console.



//: c13:ResponsiveUI.java
// Responsividade da interface com o usuário.
import com.bruceeckel.simpletest.*;

class UnresponsiveUI {
  private volatile double d = 1;
  public UnresponsiveUI() throws Exception {
    while(d > 0)
      d = d + (Math.PI + Math.E) / d;
    System.in.read(); // Nunca chega aqui
  }
}

public class ResponsiveUI extends Thread {
  private static Test monitor = new Test();
  private static volatile double d = 1;
  public ResponsiveUI() {
    setDaemon(true);
    start();
  }
  public void run() {
    while(true) {
      d = d + (Math.PI + Math.E) / d;
    }
  }
  public static void main(String[] args) throws Exception {
    //! new UnresponsiveUI(); // Este processo deve ser terminado
    new ResponsiveUI();
    Thread.sleep(300);
    System.in.read(); // 'monitor' permite entrada de dados
    System.out.println(d); // Mostra progresso
  }
} ///:~




UnresponsiveUI, ou "interface não responsiva com o usuário", faz cálculos dentro de um laço while infinito. Por isso, nunca vai poder chegar à linha de entrada de dados pela console: o computador é levado a crer que a linha de entrada de dados pode ser atingida depois do condicional while. Se for retirado o comentário da linha que cria uma UnresponsiveUI, e o programa for executado, será necessário abortar o processo para sair dele.



To make the program responsive, putting the calculation inside a run( ) method allows it to be preempted, and when you press the Enter key you’ll see that the calculation has indeed been running in the background while waiting for your user input (for testing purposes, the console input line is automatically provided to System.in.read( ) by the com.bruceeckel.simpletest.Test object, which is explained in Chapter 15).

Sharing limited resources



You can think of a single-threaded program as one lonely entity moving around through your problem space and doing one thing at a time. Because there’s only one entity, you never have to think about the problem of two entities trying to use the same resource at the same time, problems like two people trying to park in the same space, walk through a door at the same time, or even talk at the same time. Comentários (em inglês)



With multithreading, things aren’t lonely anymore, but you now have the possibility of two or more threads trying to use the same limited resource at once. Colliding over a resource must be prevented, or else you’ll have two threads trying to access the same bank account at the same time, print to the same printer, adjust the same valve, and so on. Comentários (em inglês)

Improperly accessing resources



Consider the following example in which the class “guarantees” that it will always deliver an even number when you call getValue( ). However, there’s a second thread named “Watcher” that is constantly calling getValue( ) and checking to see if this value is truly even. This seems like a needless activity, since it appears obvious by looking at the code that the value will indeed be even. But that’s where the surprise comes in. Here’s the first version of the program: Comentários (em inglês)



//: c13:AlwaysEven.java
// Demonstrating thread collision over resources by
// reading an object in an unstable intermediate state.

public class AlwaysEven {
  private int i;
  public void next() { i++; i++; }
  public int getValue() { return i; }
  public static void main(String[] args) {
    final AlwaysEven ae = new AlwaysEven();
    new Thread("Watcher") {
      public void run() {
        while(true) {
          int val = ae.getValue();
          if(val % 2 != 0) {
            System.out.println(val);
            System.exit(0);
          }
        }
      }
    }.start();
    while(true)
      ae.next();
  }
} ///:~




In main( ), an AlwaysEven object is created—it must be final because it is accessed inside the anonymous inner class defined as a Thread. If the value read by the thread is not even, it prints it out (as proof that it has caught the object in an unstable state) and then exits the program. Comentários (em inglês)



This example shows a fundamental problem with using threads. You never know when a thread might be run. Imagine sitting at a table with a fork, about to spear the last piece of food on your plate, and as your fork reaches for it, the food suddenly vanishes (because your thread was suspended and another thread came in and stole the food). That’s the problem that you’re dealing with when writing concurrent programs. Comentários (em inglês)



Sometimes you don’t care if a resource is being accessed at the same time you’re trying to use it (the food is on some other plate). But for multithreading to work, you need some way to prevent two threads from accessing the same resource, at least during critical periods. Comentários (em inglês)



Preventing this kind of collision is simply a matter of putting a lock on a resource when one thread is using it. The first thread that accesses a resource locks it, and then the other threads cannot access that resource until it is unlocked, at which time another thread locks and uses it, etc. If the front seat of the car is the limited resource, the child who shouts “Dibs!” asserts the lock. Comentários (em inglês)

A resource testing framework



Before going on, let’s try to simplify things a bit by creating a little framework for performing tests on these types of threading examples. We can accomplish this by separating out the common code that might appear across multiple examples. First, note that the “watcher” thread is actually watching for a violated invariant in a particular object. That is, the object is supposed to preserve rules about its internal state, and if you can see the object from outside in an invalid intermediate state, then the invariant has been violated from the standpoint of the client (this is not to say that the object can never exist in the invalid intermediate state, just that it should not be visible by the client in such a state). Thus, we want to be able to detect that the invariant is violated, and also know what the violation value is. To get both of these values from one method call, we combine them in a tagging interface that exists only to provide a meaningful name in the code: Comentários (em inglês)



//: c13:InvariantState.java
// Messenger carrying invariant data
public interface InvariantState {} ///:~




In this scheme, the information about success or failure is encoded in the class name and type to make the result more readable. The class indicating success is: Comentários (em inglês)



//: c13:InvariantOK.java
// Indicates that the invariant test succeeded
public class InvariantOK implements InvariantState {} ///:~




To indicate failure, the InvariantFailure object will carry an object with information about what caused the failure, typically so that it can be displayed: Comentários (em inglês)



//: c13:InvariantFailure.java
// Indicates that the invariant test failed

public class InvariantFailure implements InvariantState {
  public Object value;
  public InvariantFailure(Object value) {
    this.value = value;
  }
} ///:~




Now we can define an interface that must be implemented by any class that wishes to have its invariance tested: Comentários (em inglês)



//: c13:Invariant.java
public interface Invariant {
  InvariantState invariant();
} ///:~




Antes de se criar o thread vigia, ou "watcher", genérico, deve-se observar que alguns exemplos deste capítulo não se comportarão como esperado em todas as plataformas. Muitos dos exemplos aqui tentam mostrar violações do comportamento de um só thread quando múltiplos threads são usados, e isto pode não acontecer [69]. Ou então um exemplo pode tentar mostrar que a violação não ocorre tentando mostrar (e falhando neste ponto) em demonstrar a violação. Nestes casos, é preciso ter uma forma de interromper o programa depois de alguns segundos de execucão. A classe a seguir faz isto derivando da classe Timer da biblioteca padrão: Comentários (em inglês)



//: c13:Timeout.java
// Define um limite de tempo para a execução de um programa
import java.util.*;

public class Timeout extends Timer {
  public Timeout(int delay, final String msg) {
    super(true); // Thread daemon
    schedule(new TimerTask() {
      public void run() {
        System.out.println(msg);
        System.exit(0);
      }
    }, delay);
  }
} ///:~




O intervalo de demora, ou "delay", é em milissegundos e a mensagem será impressa quando o intervalo de tolerância, ou timeout, "terminar". Observe que quando super(true)é chamado, cria-se um thred daemon para que, se o programa terminar de alguma outra forma, este thread não o impeça de terminar totalmente. O método Timer.schedule( ) tem uma subclasse TimerTask (criada como uma classe anônima e interna) cujo método run( ) é executado depois que termina o segundo argumento de schedule( ) , chamado delay, e expresso em milissegundos. O uso de Timer é em geral mais simples e mais claro do que escrever o código diretamente usando um sleep( )explícito. Além disso, Timer é projetado para poder ser ampliado, ou "escalar", para grandes números de tarefas escalonadas (na ordem milhares) e por isso ele é uma ferramenta muito útil.Comentários (em inglês)



Now we can use the Invariant interface and the Timeout class in the InvariantWatcher thread:



//: c13:InvariantWatcher.java
// Repeatedly checks to ensure invariant is not violated

public class InvariantWatcher extends Thread {
  private Invariant invariant;
  public InvariantWatcher(Invariant invariant) {
    this.invariant = invariant;
    setDaemon(true);
    start();
  }
  // Stop everything after awhile:
  public
  InvariantWatcher(Invariant invariant, final int timeOut){
    this(invariant);
    new Timeout(timeOut,
      "Timed out without violating invariant");
  }
  public void run() {
    while(true) {
      InvariantState state = invariant.invariant();
      if(state instanceof InvariantFailure) {
        System.out.println("Invariant violated: "
          + ((InvariantFailure)state).value);
        System.exit(0);
      }
    }
  }
} ///:~




The constructor captures a reference to the Invariant object to be tested, and starts the thread. The second constructor calls the first constructor, then creates a Timeout that stops everything after a desired delay—this is used in situations where the program may not exit by violating an invariant. In run( ), the current InvariantState is captured and tested, and if it fails, the value is printed. Note that we cannot throw an exception inside this thread, because that would only terminate the thread, not the program. Comentários (em inglês)



Now AlwaysEven.java can be rewritten using the framework:



//: c13:EvenGenerator.java
// AlwaysEven.java using the invariance tester

public class EvenGenerator implements Invariant {
  private int i;
  public void next() { i++; i++; }
  public int getValue() { return i; }
  public InvariantState invariant() {
    int val = i; // Capture it in case it changes
    if(val % 2 == 0)
      return new InvariantOK();
    else
      return new InvariantFailure(new Integer(val));
  }
  public static void main(String[] args) {
    EvenGenerator gen = new EvenGenerator();
    new InvariantWatcher(gen);
    while(true)
      gen.next();
  }
} ///:~




When defining the invariant( ) method, you must capture all the values of interest into local variables. This way, you can return the actual value you have tested, not one that may have been changed (by another thread) in the meantime. Comentários (em inglês)



In this case, the problem is not that the object goes through a state that violates invariance, but that methods can be called by threads while the object is in that intermediate unstable state. Comentários (em inglês)

Colliding over resources



The worst thing that happens with EvenGenerator is that a client thread might see it in an unstable intermediate state. The object’s internal consistency is maintained, however, and it eventually becomes visible in a good state. But if two threads are actually modifying an object, the contention over shared resources is much worse, because the object can be put into an incorrect state. Comentários (em inglês)



Consider the simple concept of a semaphore, which is a flag object used for communication between threads. If the semaphore’s value is zero, then whatever it is monitoring is available, but if the value is nonzero, then the monitored entity is unavailable, and the thread must wait for it. When it’s available, the thread increments the semaphore and then goes ahead and uses the monitored entity. Because incrementing and decrementing are atomic operations (that is, they cannot be interrupted), the semaphore keeps two threads from using the same entity at the same time. Comentários (em inglês)



If the semaphore is going to properly guard the entity that it is monitoring, then it must never get into an unstable state. Here’s a simple version of the semaphore idea:



//: c13:Semaphore.java
// A simple threading flag

public class Semaphore implements Invariant {
  private volatile int semaphore = 0;
  public boolean available() { return semaphore == 0; }
  public void acquire() { ++semaphore; }
  public void release() { --semaphore; }
  public InvariantState invariant() {
    int val = semaphore;
    if(val == 0 || val == 1)
      return new InvariantOK();
    else
      return new InvariantFailure(new Integer(val));
  }
} ///:~




The core part of the class is straightforward, consisting of available( ), acquire( ), and release( ). Since a thread should check for availability before acquiring, the value of semaphore should never be other than one or zero, and this is tested by invariant( ). Comentários (em inglês)



But look what happens when Semaphore is tested for thread consistency:



//: c13:SemaphoreTester.java
// Colliding over shared resources

public class SemaphoreTester extends Thread {
  private volatile Semaphore semaphore;
  public SemaphoreTester(Semaphore semaphore) {
    this.semaphore = semaphore;
    setDaemon(true);
    start();
  }
  public void run() {
    while(true)
      if(semaphore.available()) {
        yield(); // Makes it fail faster
        semaphore.acquire();
        yield();
        semaphore.release();
        yield();
      }
  }
  public static void main(String[] args) throws Exception {
    Semaphore sem = new Semaphore();
    new SemaphoreTester(sem);
    new SemaphoreTester(sem);
    new InvariantWatcher(sem).join();
  }
} ///:~




A classe SemaphoreTester cria um thread que testa continuamente um objeto de tipo Semaphore para ver se ele está disponível. Se estiver, ele o obtém e depois o libera. Observe que o campo semaphore é volatile, ou "volátil", para garantir que o compilador não aplique uma otimização que faça desaparecer quaisquer leituras desse valor.Comentários (em inglês)



In main( ), two SemaphoreTester threads are created, and you’ll see that in short order the invariant is violated. This happens because one thread might get a true result from calling available( ), but by the time that thread calls acquire( ), the other thread may have already called acquire( ) and incremented the semaphore field. The InvariantWatcher may see the field with too high a value, or possibly see it after both threads have called release( ) and decremented it to a negative value. Note that InvariantWatcher join( )s with the main thread to keep the program running until there is a failure. Comentários (em inglês)



On my machine, I discovered that the inclusion of yield( ) caused failure to occur much faster, but this will vary with operating systems and JVM implementations. You should experiment with taking the yield( ) statements out; the failure might take a very long time to occur, which demonstrates how difficult it can be to detect a flaw in your program when you’re writing multithreaded code. Comentários (em inglês)



Esta classe enfatiza os riscos da programação concorrente: se uma classe tão simples assim pode produzir programas, não se deve nunca confiar em expectativas sobre a concorrência.Comentários (em inglês)

Resolvendo a contenção de recursos compartilhados



To solve the problem of thread collision, virtually all multithreading schemes serialize access to shared resources. This means that only one thread at a time is allowed to access the shared resource. This is ordinarily accomplished by putting a locked clause around a piece of code so that only one thread at a time may pass through that piece of code. Because this locked clause produces mutual exclusion, a common name for such a mechanism is mutex. Comentários (em inglês)



Consider the bathroom in your house; multiple people (threads) may each want to have exclusive use of the bathroom (the shared resource). To access the bathroom, a person knocks on the door to see if it’s available. If so, they enter and lock the door. Any other thread that wants to use the bathroom is “blocked” from using it, so that thread waits at the door until the bathroom is available. Comentários (em inglês)



The analogy breaks down a bit when the bathroom is released and it comes time to give access to another thread. There isn’t actually a line of people and we don’t know for sure who gets the bathroom next, because the thread scheduler isn’t deterministic that way. Instead, it’s as if there is a group of blocked threads milling about in front of the bathroom, and when the thread that has locked the bathroom unlocks it and emerges, the one that happens to be nearest the door at the moment goes in. As noted earlier, suggestions can be made to the thread scheduler via yield( ) and setPriority( ), but these suggestions may not have much of an effect depending on your platform and JVM implementation. Comentários (em inglês)



Java has built-in support to prevent collisions over resources in the form of the synchronized keyword. This works much like the Semaphore class was supposed to: When a thread wishes to execute a piece of code guarded by the synchronized keyword, it checks to see if the semaphore is available, then acquires it, executes the code, and releases it. However, synchronized is built into the language, so it’s guaranteed to always work, unlike the Semaphore class. Comentários (em inglês)



The shared resource is typically just a piece of memory in the form of an object, but may also be a file, I/O port, or something like a printer. To control access to a shared resource, you first put it inside an object. Then any method that accesses that resource can be made synchronized. This means that if a thread is inside one of the synchronized methods, all other threads are blocked from entering any of the synchronized methods of the class until the first thread returns from its call. Comentários (em inglês)



Since you typically make the data elements of a class private and access that memory only through methods, you can prevent collisions by making methods synchronized. Here is how you declare synchronized methods: Comentários (em inglês)



synchronized void f() { /* ... */ }
synchronized void g(){ /* ... */ }




Cada objeto contém uma única trava, também conhecida como monitor, que é automaticamente parte do objeto; não é necessário escrever código adicional. Quando se chama qualquer método synchronized, esse objeto é travado e nenhum outro método synchronized desse objeto pode ser chamado até que o primeiro termine e libere a trava. No exemplo anterior, se f( ) for chamada sobre um objeto, g( ) não pode ser chamada sobre o mesmo objeto até que f( ) termine e libere a trava. Assim, há uma unica trava que é compartilhada por todos os métodos synchronized de um objeto em particular, e essa trava impede a memória comum de ser escrita por mais de um thread por vez.Comentários (em inglês)



One thread may acquire an object’s lock multiple times. This happens if one method calls a second method on the same object, which in turn calls another method on the same object, etc. The JVM keeps track of the number of times the object has been locked. If the object is unlocked, it has a count of zero. As a thread acquires the lock for the first time, the count goes to one. Each time the thread acquires a lock on the same object, the count is incremented. Naturally, multiple lock acquisition is only allowed for the thread that acquired the lock in the first place. Each time the thread leaves a synchronized method, the count is decremented, until the count goes to zero, releasing the lock entirely for use by other threads. Comentários (em inglês)



There’s also a single lock per class (as part of the Class object for the class), so that synchronized static methods can lock each other out from simultaneous access of static data on a class-wide basis. Comentários (em inglês)

Synchronizing the EvenGenerator



By adding synchronized to EvenGenerator.java, we can prevent the undesirable thread access:



//: c13:SynchronizedEvenGenerator.java
// Using "synchronized" to prevent thread collisions

public
class SynchronizedEvenGenerator implements Invariant {
  private int i;
  public synchronized void next() { i++; i++; }
  public synchronized int getValue() { return i; }
  // Not synchronized so it can run at
  // any time and thus be a genuine test:
  public InvariantState invariant() {
    int val = getValue();
    if(val % 2 == 0)
      return new InvariantOK();
    else
      return new InvariantFailure(new Integer(val));
  }
  public static void main(String[] args) {
    SynchronizedEvenGenerator gen =
      new SynchronizedEvenGenerator();
    new InvariantWatcher(gen, 4000); // 4-second timeout
    while(true)
      gen.next();
  }
} ///:~




You’ll notice that both next( ) and getValue( ) are synchronized. If you synchronize only one of the methods, then the other is free to ignore the object lock and can be called with impunity. This is an important point: Every method that accesses a critical shared resource must be synchronized or it won’t work right. On the other hand, InvariantState is not synchronized because it is doing the testing, and we want it to be called at any time so that it produces a true test of the object. Comentários (em inglês)

Atomic operations



A common piece of lore often repeated in Java threading discussions is that “atomic operations do not need to be synchronized.” An atomic operation is one that cannot be interrupted by the thread scheduler; if the operation begins, then it will run to completion before the possibility of a context switch (switching execution to another thread). Comentários (em inglês)



The atomic operations commonly mentioned in this lore include simple assignment and returning a value when the variable in question is a primitive type that is not a long or a double. The latter types are excluded because they are larger than the rest of the types, and the JVM is thus not required to perform reads and assignments as single atomic operations (a JVM may choose to do so anyway, but there’s no guarantee). However, you do get atomicity if you use the volatile keyword with long or double. Comentários (em inglês)



If you were to blindly apply the idea of atomicity to SynchronizedEvenGenerator.java, you would notice that



  public synchronized int getValue() { return i; }




fits the description. But try removing synchronized, and the test will fail, because even though return i is indeed an atomic operation, removing synchronized allows the value to be read while the object is in an unstable intermediate state. You must genuinely understand what you’re doing before you try to apply optimizations like this. There are no easily-applicable rules that work. Comentários (em inglês)



As a second example, consider something even simpler: a class that produces serial numbers.[70] Each time nextSerialNumber( ) is called, it must return a unique value to the caller:



//: c13:SerialNumberGenerator.java

public class SerialNumberGenerator {
  private static volatile int serialNumber = 0;
  public static int nextSerialNumber() {
    return serialNumber++;
  }
} ///:~




SerialNumberGenerator is about as simple a class as you can imagine, and if you’re coming from C++ or some other low-level background, you would expect the increment to be an atomic operation, because increment is usually implemented as a microprocessor instruction. However, in the JVM an increment is not atomic and involves both a read and a write, so there’s room for threading problems even in such a simple operation. Comentários (em inglês)



The serialNumber field is volatile because it is possible for each thread to have a local stack and maintain copies of some variables there. If you define a variable as volatile, it tells the compiler not to do any optimizations that would remove reads and writes that keep the field in exact synchronization with the local data in the threads. Comentários (em inglês)



To test this, we need a set that doesn’t run out of memory, in case it takes a long time to detect a problem. The CircularSet shown here reuses the memory used to store ints, with the assumption that by the time you wrap around, the possibility of a collision with the overwritten values is minimal. The add( ) and contains( ) methods are synchronized to prevent thread collisions: Comentários (em inglês)



//: c13:SerialNumberChecker.java
// Operations that may seem safe are not,
// when threads are present.

// Reuses storage so we don't run out of memory:
class CircularSet {
  private int[] array;
  private int len;
  private int index = 0;
  public CircularSet(int size) {
    array = new int[size];
    len = size;
    // Initialize to a value not produced
    // by the SerialNumberGenerator:
    for(int i = 0; i < size; i++)
      array[i] = -1;
  }
  public synchronized void add(int i) {
    array[index] = i;
    // Wrap index and write over old elements:
    index = ++index % len;
  }
  public synchronized boolean contains(int val) {
    for(int i = 0; i < len; i++)
      if(array[i] == val) return true;
    return false;
  }
}

public class SerialNumberChecker {
  private static CircularSet serials =
    new CircularSet(1000);
  static class SerialChecker extends Thread {
    SerialChecker() { start(); }
    public void run() {
      while(true) {
        int serial =
          SerialNumberGenerator.nextSerialNumber();
        if(serials.contains(serial)) {
          System.out.println("Duplicate: " + serial);
          System.exit(0);
        }
        serials.add(serial);
      }
    }
  }
  public static void main(String[] args) {
    for(int i = 0; i < 10; i++)
      new SerialChecker();
    // Stop after 4 seconds:
    new Timeout(4000, "No duplicates detected");
  }
} ///:~




SerialNumberChecker possui um static CircularSet que contém todos os números seriais que foram extraídos, além de um objeto Thread aninhado que obtém números seriais e garante que eles sejam únicos. Quando se criam múltiplos threads que disputam números seriais, percebe-se que os threads obtém um número serial duplicado em tempo razoavelmente pequeno. Observe que este programa pode não mostrar uma colisão em sua máquina, mas ele definitivamente detectou colisões uma máquina multiprocessada. Para resolver este problema, acrescente a palavra-chave synchronized ao método nextSerialNumber( ). Comentários (em inglês)



The atomic operations that are supposed to be safe are reading and assignment of primitives. However, as seen in EvenGenerator.java, it’s still easily possible to use an atomic operation that accesses your object while it’s in an unstable intermediate state, so you cannot make any assumptions. On top of this, the atomic operations are not guaranteed to work with long and double (although some JVM implementations do guarantee atomicity for long and double operations, you won’t be writing portable code if you depend on this). Comentários (em inglês)



It’s safest to use the following guidelines:

  1. If you need to synchronize one method in a class, synchronize all of them. It’s often difficult to tell for sure if a method will be negatively affected if you leave synchronization out. Feedback
  2. Be extremely careful when removing synchronization from methods. The typical reason to do this is for performance, but in JDK 1.3 and 1.4 the overhead of synchronized has been greatly reduced. In addition, you should only do this after using a profiler to determine that synchronized is indeed the bottleneck. Feedback

Fixing Semaphore



Now consider Semaphore.java. It would seem that we should be able to repair this by synchronizing the three class methods, like this:



//: c13:SynchronizedSemaphore.java
// Colliding over shared resources

public class SynchronizedSemaphore extends Semaphore {
  private volatile int semaphore = 0;
  public synchronized boolean available() {
    return semaphore == 0;
  }
  public synchronized void acquire() { ++semaphore; }
  public synchronized void release() { --semaphore; }
  public InvariantState invariant() {
    int val = semaphore;
    if(val == 0 || val == 1)
      return new InvariantOK();
    else
      return new InvariantFailure(new Integer(val));
  }
  public static void main(String[] args) throws Exception {
    SynchronizedSemaphore sem =new SynchronizedSemaphore();
    new SemaphoreTester(sem);
    new SemaphoreTester(sem);
    new InvariantWatcher(sem).join();
  }
} ///:~




This looks rather odd at first—SynchronizedSemaphore is inherited from Semaphore, and yet all the overridden methods are synchronized, but the base-class versions aren’t. Java doesn’t allow you to change the method signature during overriding, and yet doesn’t complain about this. That’s because the synchronized keyword is not part of the method signature, so you can add it in and it doesn’t limit overriding. Comentários (em inglês)



The reason for inheriting from Semaphore is to reuse the SemaphoreTester class. When you run the program you’ll see that it still causes an InvariantFailure. Comentários (em inglês)



Why does this fail? By the time a thread detects that the Semaphore is available because available( ) returns true, it has released the lock on the object. Another thread can dash in and increment the semaphore value before the first thread does. The first thread still assumes the Semaphore object is available and so goes ahead and blindly enters the acquire( ) method, putting the object into an unstable state. This is just one more lesson about rule zero of concurrent programming: Never make any assumptions. Comentários (em inglês)



The only solution to this problem is to make the test for availability and the acquisition a single atomic operation—which is exactly what the synchronized keyword provides in conjunction with the lock on an object. That is, Java’s lock and synchronized keyword is a built-in semaphore mechanism, so you don’t need to create your own. Comentários (em inglês)

Critical sections



Sometimes, you only want to prevent multiple thread access to part of the code inside a method instead of the entire method. The section of code you want to isolate this way is called a critical section and is also created using the synchronized keyword. Here, synchronized is used to specify the object whose lock is being used to synchronize the enclosed code: Comentários (em inglês)



synchronized(syncObject) {
  // This code can be accessed 
  // by only one thread at a time
}




This is also called a synchronized block; before it can be entered, the lock must be acquired on syncObject. If some other thread already has this lock, then the critical section cannot be entered until the lock is given up. Comentários (em inglês)



The following example compares both approaches to synchronization by showing how the time available for other threads to access an object is significantly increased by using a synchronized block instead of synchronizing an entire method. In addition, it shows how an unprotected class can be used in a multithreaded situation if it is controlled and protected by another class: Comentários (em inglês)



//: c13:CriticalSection.java
// Synchronizing blocks instead of entire methods. Also
// demonstrates protection of a non-thread-safe class
// with a thread-safe one.
import java.util.*;

class Pair { // Not thread-safe
  private int x, y;
  public Pair(int x, int y) {
    this.x = x;
    this.y = y;
  }
  public Pair() { this(0, 0); }
  public int getX() { return x; }
  public int getY() { return y; }
  public void incrementX() { x++; }
  public void incrementY() { y++; }
  public String toString() {
    return "x: " + x + ", y: " + y;
  }
  public class PairValuesNotEqualException
  extends RuntimeException {
    public PairValuesNotEqualException() {
      super("Pair values not equal: " + Pair.this);
    }
  }
  // Arbitrary invariant -- both variables must be equal:
  public void checkState() {
    if(x != y)
      throw new PairValuesNotEqualException();
  }
}

// Protect a Pair inside a thread-safe class:
abstract class PairManager {
  protected Pair p = new Pair();
  private List storage = new ArrayList();
  public synchronized Pair getPair() {
    // Make a copy to keep the original safe:
    return new Pair(p.getX(), p.getY());
  }
  protected void store() { storage.add(getPair()); }
  // A "template method":
  public abstract void doTask();
}

// Synchronize the entire method:
class PairManager1 extends PairManager {
  public synchronized void doTask() {
    p.incrementX();
    p.incrementY();
    store();
  }
}

// Use a critical section:
class PairManager2 extends PairManager {
  public void doTask() {
    synchronized(this) {
      p.incrementX();
      p.incrementY();
    }
    store();
  }
}

class PairManipulator extends Thread {
  private PairManager pm;
  private int checkCounter = 0;
  private class PairChecker extends Thread {
    PairChecker() { start(); }
    public void run() {
      while(true) {
        checkCounter++;
        pm.getPair().checkState();
      }
    }
  }
  public PairManipulator(PairManager pm) {
    this.pm = pm;
    start();
    new PairChecker();
  }
  public void run() {
    while(true) {
      pm.doTask();
    }
  }
  public String toString() {
    return "Pair: " + pm.getPair() +
      " checkCounter = " + checkCounter;
  }
}

public class CriticalSection {
  public static void main(String[] args) {
    // Test the two different approaches:
    final PairManipulator
      pm1 = new PairManipulator(new PairManager1()),
      pm2 = new PairManipulator(new PairManager2());
    new Timer(true).schedule(new TimerTask() {
      public void run() {
        System.out.println("pm1: " + pm1);
        System.out.println("pm2: " + pm2);
        System.exit(0);
      }
    }, 500); // run() after 500 milliseconds
  }
} ///:~




As noted, Pair is not thread-safe because its invariant (admittedly arbitrary) requires that both variables maintain the same values. In addition, as seen earlier in this chapter, the increment operations are not thread-safe, and because none of the methods are synchronized, you can’t trust a Pair object to stay uncorrupted in a threaded program. Comentários (em inglês)



The PairManager class holds a Pair object and controls all access to it. Note that the only public methods are getPair( ), which is synchronized, and the abstract doTask( ). Synchronization for this method will be handled when it is implemented. Comentários (em inglês)



The structure of PairManager, where some of the functionality is implemented in the base class with one or more abstract methods defined in derived classes, is called a Template Method in Design Patterns parlance.[71] Design patterns allow you to encapsulate change in your code; here, the part that is changing is the template method doTask( ). In PairManager1 the entire doTask( ) is synchronized, but in PairManager2 only part of doTask( ) is synchronized by using a synchronized block. Note that the synchronized keyword is not part of the method signature and thus may be added during overriding. Comentários (em inglês)



PairManager2 is observing, in effect, that store( ) is a protected method and thus is not available to the general client, but only to subclasses. Thus, it doesn’t necessarily need to be guarded inside a synchronized method, and is instead placed outside of the synchronized block. Comentários (em inglês)



A synchronized block must be given an object to synchronize upon, and usually the most sensible object to use is just the current object that the method is being called for: synchronized(this), which is the approach taken in PairManager2. That way, when the lock is acquired for the synchronized block, other synchronized methods in the object cannot be called. So the effect is that of simply reducing the scope of synchronization. Comentários (em inglês)



Sometimes this isn’t what you want, in which case you can create a separate object and synchronize on that. The following example demonstrates that two threads can enter an object when the methods in that object synchronize on different locks: Comentários (em inglês)



//: c13:SyncObject.java
// Synchronizing on another object
import com.bruceeckel.simpletest.*;

class DualSynch {
  private Object syncObject = new Object();
  public synchronized void f() {
    System.out.println("Inside f()");
    // Doesn't release lock:
    try {
      Thread.sleep(500);
    } catch(InterruptedException e) {
      throw new RuntimeException(e);
    }
    System.out.println("Leaving f()");
  }
  public void g() {
    synchronized(syncObject) {
      System.out.println("Inside g()");
      try {
        Thread.sleep(500);
      } catch(InterruptedException e) {
        throw new RuntimeException(e);
      }
      System.out.println("Leaving g()");
    }
  }
}

public class SyncObject {
  private static Test monitor = new Test();
  public static void main(String[] args) {
    final DualSynch ds = new DualSynch();
    new Thread() {
      public void run() {
        ds.f();
      }
    }.start();
    ds.g();
    monitor.expect(new String[] {
      "Inside g()",
      "Inside f()",
      "Leaving g()",
      "Leaving f()"
    }, Test.WAIT + Test.IGNORE_ORDER);
  }
} ///:~




The DualSync method f( ) synchronizes on this (by synchronizing the entire method) and g( ) has a synchronized block that synchronizes on syncObject. Thus, the two synchronizations are independent. This is demonstrated in main( ) by creating a Thread that calls f( ). The main( ) thread is used to call g( ). You can see from the output that both methods are running at the same time, so neither one is blocked by the synchronization of the other. Comentários (em inglês)



Returning to CriticalSection.java, PairManipulator is created to test the two different types of PairManager by running doTask( ) in one thread and an instance of the inner class PairChecker in the other. To trace how often it is able to run the test, PairChecker increments checkCounter every time it is successful. In main( ), two PairManipulator objects are created and allowed to run for awhile. When the Timer runs out, it executes its run( ) method, that displays the results of each PairManipulator and exits. When you run the program, you should see something like this: Comentários (em inglês)



pm1: Pair: x: 58892, y: 58892 checkCounter = 44974
pm2: Pair: x: 73153, y: 73153 checkCounter = 100535




Although you will probably see a lot of variation from one run to the next, in general you will see that PairManager1.doTask( ) does not allow the PairChecker nearly as much access as PairManager2.doTask( ), which has the synchronized block and thus provides more unlocked time. This is typically the reason that you want to use a synchronized block instead of synchronizing the whole method: to allow other threads more access (as long as it is safe to do so). Comentários (em inglês)



Of course, all synchronization depends on programmer diligence: Every piece of code that can access a shared resource must be wrapped in an appropriate synchronized block. Comentários (em inglês)

Thread states



A thread can be in any one of four states:

  1. New: The thread object has been created, but it hasn’t been started yet, so it cannot run. Feedback
  2. Runnable: This means that a thread can be run when the time-slicing mechanism has CPU cycles available for the thread. Thus, the thread might or might not be running at any moment, but there’s nothing to prevent it from being run if the scheduler can arrange it; it’s not dead or blocked. Feedback
  3. Dead: The normal way for a thread to die is by returning from its run( ) method. Before it was deprecated in Java 2, you could also call stop( ), but this could easily put your program into an unstable state. There’s also a destroy( ) method (which has never been implemented, and probably never will be, so it’s effectively deprecated). You’ll learn about an alternative way to code a stop( ) equivalent later in the chapter. Feedback
  4. Blocked: The thread could be run, but there’s something that prevents it. While a thread is in the blocked state, the scheduler will simply skip over it and not give it any CPU time. Until a thread reenters the runnable state, it won’t perform any operations. Feedback

Becoming blocked



When a thread is blocked, there’s some reason that it cannot continue running. A thread can become blocked for the following reasons: Comentários (em inglês)

  1. You’ve put the thread to sleep by calling sleep(milliseconds), in which case it will not be run for the specified time. Feedback
  2. You’ve suspended the execution of the thread with wait( ). It will not become runnable again until the thread gets the notify( ) or notifyAll( ) message. We’ll examine these in the next section. Feedback
  3. The thread is waiting for some I/O to complete. Feedback
  4. The thread is trying to call a synchronized method on another object, and that object’s lock is not available. Feedback


In old code, you may also see suspend( ) and resume( ) used to block and unblock threads, but these are deprecated in Java 2 (because they are deadlock-prone), and so will not be examined in this book. Comentários (em inglês)

Cooperation between threads



After understanding that threads can collide with each other, and how you keep them from colliding, the next step is to learn how to make threads cooperate with each other. The key to doing this is by handshaking between threads, which is safely implemented using the Object methods wait( ) and notify( ). Comentários (em inglês)

Wait and notify



It’s important to understand that sleep( ) does not release the lock when it is called. On the other hand, the method wait( ) does release the lock, which means that other synchronized methods in the thread object can be called during a wait( ). When a thread enters a call to wait( ) inside a method, that thread’s execution is suspended, and the lock on that object is released. Comentários (em inglês)



There are two forms of wait( ). The first takes an argument in milliseconds that has the same meaning as in sleep( ): “Pause for this period of time.” The difference is that in wait( ):

  1. The object lock is released during the wait( ).
  2. You can come out of the wait( ) due to a notify( ) or notifyAll( ), or by letting the clock run out. Feedback


The second form of wait( ) takes no arguments; this version is more commonly used. This wait( ) continues indefinitely until the thread receives a notify( ) or notifyAll( ). Comentários (em inglês)



One fairly unique aspect of wait( ), notify( ), and notifyAll( ) is that these methods are part of the base class Object and not part of Thread, as is sleep( ). Although this seems a bit strange at first—to have something that’s exclusively for threading as part of the universal base class—it’s essential because they manipulate the lock that’s also part of every object. As a result, you can put a wait( ) inside any synchronized method, regardless of whether that class extends Thread or implements Runnable. In fact, the only place you can call wait( ), notify( ), or notifyAll( ) is within a synchronized method or block (sleep( ) can be called within non-synchronized methods since it doesn’t manipulate the lock). If you call any of these within a method that’s not synchronized, the program will compile, but when you run it, you’ll get an IllegalMonitorStateException with the somewhat nonintuitive message “current thread not owner.” This message means that the thread calling wait( ), notify( ), or notifyAll( ) must “own” (acquire) the lock for the object before it can call any of these methods. Comentários (em inglês)



You can ask another object to perform an operation that manipulates its own lock. To do this, you must first capture that object’s lock. For example, if you want to notify( ) an object x, you must do so inside a synchronized block that acquires the lock for x: Comentários (em inglês)



synchronized(x) {
  x.notify();
}




Typically, wait( ) is used when you’re waiting for some condition that is under the control of forces outside of the current method to change (typically, this condition will be changed by another thread). You don’t want to idly wait while testing the condition inside your thread; this is called a “busy wait” and it’s a very bad use of CPU cycles. So wait( ) allows you to put the thread to sleep while waiting for the world to change, and only when a notify( ) or notifyAll( ) occurs does the thread wake up and check for changes. Thus, wait( ) provides a way to synchronize activities between threads. Comentários (em inglês)



As an example, consider a restaurant that has one chef and one waitperson. The waitperson must wait for the chef to prepare a meal. When the chef has a meal ready, the chef notifies the waitperson, who then gets the meal and goes back to waiting. This is an excellent example of thread cooperation: The chef represents the producer, and the waitperson represents the consumer. Here is the story modeled in code: Comentários (em inglês)



//: c13:Restaurant.java
// The producer-consumer approach to thread cooperation.
import com.bruceeckel.simpletest.*;

class Order {
  private static int i = 0;
  private int count = i++;
  public Order() {
    if(count == 10) {
      System.out.println("Out of food, closing");
      System.exit(0);
    }
  }
  public String toString() { return "Order " + count; }
}

class WaitPerson extends Thread {
  private Restaurant restaurant;
  public WaitPerson(Restaurant r) {
    restaurant = r;
    start();
  }
  public void run() {
    while(true) {
      while(restaurant.order == null)
        synchronized(this) {
          try {
            wait();
          } catch(InterruptedException e) {
            throw new RuntimeException(e);
          }
        }
      System.out.println(
        "Waitperson got " + restaurant.order);
      restaurant.order = null;
    }
  }
}

class Chef extends Thread {
  private Restaurant restaurant;
  private WaitPerson waitPerson;
  public Chef(Restaurant r, WaitPerson w) {
    restaurant = r;
    waitPerson = w;
    start();
  }
  public void run() {
    while(true) {
      if(restaurant.order == null) {
        restaurant.order = new Order();
        System.out.print("Order up! ");
        synchronized(waitPerson) {
          waitPerson.notify();
        }
      }
      try {
        sleep(100);
      } catch(InterruptedException e) {
        throw new RuntimeException(e);
      }
    }
  }
}

public class Restaurant {
  private static Test monitor = new Test();
  Order order; // Package access
  public static void main(String[] args) {
    Restaurant restaurant = new Restaurant();
    WaitPerson waitPerson = new WaitPerson(restaurant);
    Chef chef = new Chef(restaurant, waitPerson);
    monitor.expect(new String[] {
      "Order up! Waitperson got Order 0",
      "Order up! Waitperson got Order 1",
      "Order up! Waitperson got Order 2",
      "Order up! Waitperson got Order 3",
      "Order up! Waitperson got Order 4",
      "Order up! Waitperson got Order 5",
      "Order up! Waitperson got Order 6",
      "Order up! Waitperson got Order 7",
      "Order up! Waitperson got Order 8",
      "Order up! Waitperson got Order 9",
      "Out of food, closing"
    }, Test.WAIT);
  }
} ///:~




Order is a simple self-counting class, but notice that it also includes a way to terminate the program; on order 10, System.exit( ) is called. Comentários (em inglês)



A WaitPerson must know what Restaurant they are working for because they must fetch the order from the restaurant’s “order window,” restaurant.order. In run( ), the WaitPerson goes into wait( ) mode, stopping that thread until it is woken up with a notify( ) from the Chef. Since this is a very simple program, we know that only one thread will be waiting on the WaitPerson’s lock: the WaitPerson thread itself. For this reason it’s safe to call notify( ). In more complex situations, multiple threads may be waiting on a particular object lock, so you don’t know which thread should be awakened. The solutions is to call notifyAll( ), which wakes up all the threads waiting on that lock. Each thread must then decide whether the notification is relevant. Comentários (em inglês)



Notice that the wait( ) is wrapped in a while( ) statement that is testing for the same thing that is being waited for. This seems a bit strange at first—if you’re waiting for an order, once you wake up the order must be available, right? The problem is that in a multithreading application, some other thread might swoop in and grab the order while the WaitPerson is waking up. The only safe approach is to always use the following idiom for a wait( ): Comentários (em inglês)



while(conditionIsNotMet)
wait( );



This guarantees that the condition will be met before you get out of the wait loop, and if you have either been notified of something that doesn’t concern the condition (as can happen with notifyAll( )), or the condition changes before you get fully out of the wait loop, you are guaranteed to go back into waiting. Comentários (em inglês)



A Chef object must know what restaurant he or she is working for (so the Orders can be placed in restaurant.order) and the WaitPerson who is picking up the meals, so that WaitPerson can be notified when an order is ready. In this simplified example, the Chef is generating the Order objects, then notifying the WaitPerson that an order is ready. Comentários (em inglês)



Observe that the call to notify( ) must first capture the lock on waitPerson. The call to wait( ) in WaitPerson.run( ) automatically releases the lock, so this is possible. Because the lock must be owned in order to call notify( ), it’s guaranteed that two threads trying to call notify( ) on one object won’t step on each other’s toes. Comentários (em inglês)



The preceding example has only a single spot for one thread to store an object so that another thread can later use that object. However, in a typical producer-consumer implementation, you use a first-in, first-out queue in order to store the objects being produced and consumed. See the exercises at the end of the chapter to learn more about this. Comentários (em inglês)

Using Pipes for I/O between threads



It’s often useful for threads to communicate with each other by using I/O. Threading libraries may provide support for inter-thread I/O in the form of pipes. These exist in the Java I/O library as the classes PipedWriter (which allows a thread to write into a pipe) and PipedReader (which allows a different thread to read from the same pipe). This can be thought of as a variation of the producer-consumer problem, where the pipe is the canned solution. Comentários (em inglês)



Here’s a simple example in which two threads use a pipe to communicate:



//: c13:PipedIO.java
// Using pipes for inter-thread I/O
import java.io.*;
import java.util.*;

class Sender extends Thread {
  private Random rand = new Random();
  private PipedWriter out = new PipedWriter();
  public PipedWriter getPipedWriter() { return out; }
  public void run() {
    while(true) {
      for(char c = 'A'; c <= 'z'; c++) {
        try {
          out.write(c);
          sleep(rand.nextInt(500));
        } catch(Exception e) {
          throw new RuntimeException(e);
        }
      }
    }
  }
}

class Receiver extends Thread {
  private PipedReader in;
  public Receiver(Sender sender) throws IOException {
    in = new PipedReader(sender.getPipedWriter());
  }
  public void run() {
    try {
      while(true) {
        // Blocks until characters are there:
        System.out.println("Read: " + (char)in.read());
      }
    } catch(IOException e) {
      throw new RuntimeException(e);
    }
  }
}

public class PipedIO {
  public static void main(String[] args) throws Exception {
    Sender sender = new Sender();
    Receiver receiver = new Receiver(sender);
    sender.start();
    receiver.start();
    new Timeout(4000, "Terminated");
  }
} ///:~




Sender and Receiver represent threads that are performing some tasks and need to communicate with each other. Sender creates a PipedWriter, which is a standalone object, but inside Receiver the creation of PipedReader must be associated with a PipedWriter in the constructor. The Sender puts data into the Writer and sleeps for a random amount of time. However, Receiver has no sleep( ) or wait( ). But when it does a read( ), it automatically blocks when there is no more data. You get the effect of a producer-consumer, but no wait( ) loop is necessary. Comentários (em inglês)



Notice that the sender and receiver are started in main( ), after the objects are completely constructed. If you don’t start completely constructed objects, the pipe can produce inconsistent behavior on different platforms. Comentários (em inglês)

More sophisticated cooperation



Only the most basic cooperation approach (producer-consumer, usually implemented with wait( ) and notify( )/notifyAll( )) has been introduced in this section. This will solve most kinds of thread cooperation problems, but there are numerous more sophisticated approaches that are described in more advanced texts (in particular, Lea, noted at the end of this chapter). Comentários (em inglês)

Deadlock



Because threads can become blocked and because objects can have synchronized methods that prevent threads from accessing that object until the synchronization lock is released, it’s possible for one thread to get stuck waiting for another thread, which in turn waits for another thread, etc., until the chain leads back to a thread waiting on the first one. You get a continuous loop of threads waiting on each other, and no one can move. This is called deadlock. Comentários (em inglês)



If you try running a program and it deadlocks right away, you immediately know you have a problem and you can track it down. The real problem is when your program seems to be working fine but has the hidden potential to deadlock. In this case you may get no indication that deadlocking is a possibility, so it will be latent in your program until it unexpectedly happens to a customer (and you probably won’t be able to easily reproduce it). Thus, preventing deadlock by careful program design is a critical part of developing concurrent programs. Comentários (em inglês)



Let’s look at the classic demonstration of deadlock, invented by Dijkstra: the dining philosophers problem. The basic description specifies five philosophers (but the example shown here will allow any number). These philosophers spend part of their time thinking and part of their time eating. While they are thinking, they don’t need any shared resources, but when they are eating, they sit at a table with a limited number of utensils. In the original problem description, the utensils are forks, and two forks are required to get spaghetti from a bowl in the middle of the table, but it seems to make more sense to say that the utensils are chopsticks; clearly, each philosopher will require two chopsticks in order to eat. Comentários (em inglês)



A difficulty is introduced into the problem: As philosophers, they have very little money, so they can only afford five chopsticks. These are spaced around the table between them. When a philosopher wants to eat, he or she must get the chopstick to the left and the one to the right. If the philosopher on either side is using the desired chopstick, then our philosopher must wait. Comentários (em inglês)



Note that the reason this problem is interesting is because it demonstrates that a program can appear to run correctly but actually be deadlock prone. To show this, the command-line arguments allow you to adjust the number of philosophers and a factor to affect the amount of time each philosopher spends thinking. If you have lots of philosophers and/or they spend a lot of time thinking, you may never see the deadlock even though it remains a possibility. The default command-line arguments tend to make it deadlock fairly quickly: Comentários (em inglês)



//: c13:DiningPhilosophers.java
// Demonstrates how deadlock can be hidden in a program.
// {Args: 5 0 deadlock 4}
import java.util.*;

class Chopstick {
  private static int counter = 0;
  private int number = counter++;
  public String toString() {
    return "Chopstick " + number;
  }
}

class Philosopher extends Thread {
  private static Random rand = new Random();
  private static int counter = 0;
  private int number = counter++;
  private Chopstick leftChopstick;
  private Chopstick rightChopstick;
  static int ponder = 0; // Package access
  public Philosopher(Chopstick left, Chopstick right) {
    leftChopstick = left;
    rightChopstick = right;
    start();
  }
  public void think() {
    System.out.println(this + " thinking");
    if(ponder > 0)
      try {
        sleep(rand.nextInt(ponder));
      } catch(InterruptedException e) {
        throw new RuntimeException(e);
      }
  }
  public void eat() {
    synchronized(leftChopstick) {
      System.out.println(this + " has "
        + this.leftChopstick + " Waiting for "
        + this.rightChopstick);
      synchronized(rightChopstick) {
        System.out.println(this + " eating");
      }
    }
  }
  public String toString() {
    return "Philosopher " + number;
  }
  public void run() {
    while(true) {
      think();
      eat();
    }
  }
}

public class DiningPhilosophers {
  public static void main(String[] args) {
    if(args.length < 3) {
      System.err.println("usage:\n" +
        "java DiningPhilosophers numberOfPhilosophers " +
        "ponderFactor deadlock timeout\n" +
        "A nonzero ponderFactor will generate a random " +
        "sleep time during think().\n" +
        "If deadlock is not the string " +
        "'deadlock', the program will not deadlock.\n" +
        "A nonzero timeout will stop the program after " +
        "that number of seconds.");
      System.exit(1);
    }
    Philosopher[] philosopher =
      new Philosopher[Integer.parseInt(args[0])];
    Philosopher.ponder = Integer.parseInt(args[1]);
    Chopstick
      left = new Chopstick(),
      right = new Chopstick(),
      first = left;
    int i = 0;
    while(i < philosopher.length - 1) {
      philosopher[i++] =
        new Philosopher(left, right);
      left = right;
      right = new Chopstick();
    }
    if(args[2].equals("deadlock"))
      philosopher[i] = new Philosopher(left, first);
    else // Swapping values prevents deadlock:
      philosopher[i] = new Philosopher(first, left);
    // Optionally break out of program:
    if(args.length >= 4) {
      int delay = Integer.parseInt(args[3]);
      if(delay != 0)
        new Timeout(delay * 1000, "Timed out");
    }
  }
} ///:~




Both Chopstick and Philosopher use an auto-incremented static counter to give each element an identification number. Each Philosopher is given a reference to a left and right Chopstick object; these are the utensils that must be picked up before that Philosopher can eat. Comentários (em inglês)



The static field ponder indicates whether the philosophers will spend any time thinking. If the value is nonzero, then it will be used to randomly generate a sleep time inside think( ). This way, you can show that if your threads (philosophers) are spending more time on other tasks (thinking) then they have a much lower probability of requiring the shared resources (chopsticks) and thus you can convince yourself that the program is deadlock free, even though it isn’t. Comentários (em inglês)



Inside eat( ), a Philosopher acquires the left chopstick by synchronizing on it. If the chopstick is unavailable, then the philosopher blocks while waiting. When the left chopstick is acquired, the right one is acquired the same way. After eating, the right chopstick is released, then the left. Comentários (em inglês)



In run( ), each Philosopher just thinks and eats continuously. Comentários (em inglês)



The main( ) method requires at least three arguments and prints a usage message if these are not present. The third argument can be the string “deadlock,” in which case the deadlocking version of the program is used. Any other string will cause the non-deadlocking version to be used. The last (optional) argument is a timeout factor, which will abort the program after that number of seconds (whether it’s deadlocked or not). The timeout is necessary for the program to be run automatically as part of the book code testing process. Comentários (em inglês)



After the array of Philosopher is created and the ponder value is set, two Chopstick objects are created, and the first one is also stored in the first variable for use later. Every reference in the array except the last one is initialized by creating a new Philosopher object and handing it the left and right chopsticks. After each initialization, the left chopstick is moved to the right and the right is given a new Chopstick object to be used for the next Philosopher. Comentários (em inglês)



In the deadlocking version, the last Philosopher is given the left chopstick and the first chopstick that was stored earlier. That’s because the last Philosopher is sitting right next to the very first one, and they both share that first chopstick. With this arrangement, it’s possible at some point for all the philosophers to be trying to eat and waiting on the philosopher next to them to put down their chopstick, and the program will deadlock. Comentários (em inglês)



Try experimenting with different command-line values to see how the program behaves, and in particular to see all the ways that the program can appear to be executing without deadlock. Comentários (em inglês)



To repair the problem, you must understand that deadlock can occur if four conditions are simultaneously met: Comentários (em inglês)

  1. Mutual exclusion: At least one resource used by the threads must not be shareable. In this case, a chopstick can be used by only one philosopher at a time. Feedback
  2. At least one process must be holding a resource and waiting to acquire a resource currently held by another process. That is, for deadlock to occur, a philosopher must be holding one chopstick and waiting for the other one. Feedback
  3. A resource cannot be preemptively taken away from a process. All processes must only release resources as a normal event. Our philosophers are polite and they don’t grab chopsticks from other philosophers. Feedback
  4. A circular wait must happen, whereby a process waits on a resource held by another process, which in turn is waiting on a resource held by another process, and so on, until one of the processes is waiting on a resource held by the first process, thus gridlocking everything. In this example, the circular wait happens because each philosopher tries to get the left chopstick first and then the right. In the preceding example, the deadlock is broken by swapping the initialization order in the constructor for the last philosopher, causing that last philosopher to actually get the right chopstick first, then the left. Feedback


Because all of these conditions must be met in order to cause deadlock, you only need to stop one of them from occurring in order to prevent deadlock. In this program, the easiest way to prevent deadlock is to break condition four. This condition happens because each philosopher is trying to pick up their chopsticks in a particular sequence: first left, then right. Because of that, it’s possible to get into a situation where each of them is holding their left chopstick and waiting to get the right one, causing the circular wait condition. However, if the last philosopher is initialized to try to get the right chopstick first and then the left, then that philosopher will never prevent the philosopher on the immediate left from picking up his or her right chopstick, so the circular wait is prevented. This is only one solution to the problem, but you could also solve it by preventing one of the other conditions (see more advanced threading books for more details). Comentários (em inglês)



There is no Java language support to help prevent deadlock; it’s up to you to avoid it by careful design. These are not comforting words to the person who’s trying to debug a deadlocking program. Comentários (em inglês)

The proper way to stop



One change that was introduced in Java 2 to reduce the possibility of deadlock is the deprecation of the Thread class’s stop( ), suspend( ), and resume( ) methods. Comentários (em inglês)



The reason that the stop( ) method is deprecated is because it doesn’t release the locks that the thread has acquired, and if the objects are in an inconsistent state (“damaged”), other threads can view and modify them in that state. The resulting problems can be subtle and difficult to detect. Instead of using stop( ), you should use a flag to tell the thread when to terminate itself by exiting its run( ) method. Here’s a simple example: Comentários (em inglês)



//: c13:Stopping.java
// The safe way to stop a thread.
import java.util.*;

class CanStop extends Thread {
  // Must be volatile:
  private volatile boolean stop = false;
  private int counter = 0;
  public void run() {
    while(!stop && counter < 10000) {
      System.out.println(counter++);
    }
    if(stop)
      System.out.println("Detected stop");
  }
  public void requestStop() { stop = true; }
}

public class Stopping {
  public static void main(String[] args) {
    final CanStop stoppable = new CanStop();
    stoppable.start();
    new Timer(true).schedule(new TimerTask() {
      public void run() {
        System.out.println("Requesting stop");
        stoppable.requestStop();
      }
    }, 500); // run() after 500 milliseconds
  }
} ///:~            




The flag stop must be volatile so that the run( ) method is sure to see it (otherwise the value may be cached locally). The “job” of this thread is to print out 10,000 numbers, so it is finished whenever counter >= 10000 or someone requests a stop. Note that requestStop( ) is not synchronized because stop is both boolean (changing it to true is an atomic operation) and volatile. Comentários (em inglês)



In main( ), a CanStop object is started, then a Timer is set up to call requestStop( ) after one half second. The constructor for Timer is passed the argument true to make it a daemon thread so that it doesn’t prevent the program from terminating. Comentários (em inglês)

Interrupting a blocked thread



There are times when a thread blocks—such as when it is waiting for input—and it cannot poll a flag as it does in the previous example. In these cases, you can use the Thread.interrupt( ) method to break out of the blocked code: Comentários (em inglês)



//: c13:Interrupt.java
// Using interrupt() to break out of a blocked thread.
import java.util.*;

class Blocked extends Thread {
  public Blocked() {
    System.out.println("Starting Blocked");
    start();
  }
  public void run() {
    try {
      synchronized(this) {
        wait(); // Blocks
      }
    } catch(InterruptedException e) {
      System.out.println("Interrupted");
    }
    System.out.println("Exiting run()");
  }
}

public class Interrupt {
  static Blocked blocked = new Blocked();
  public static void main(String[] args) {
    new Timer(true).schedule(new TimerTask() {
      public void run() {
        System.out.println("Preparing to interrupt");
        blocked.interrupt();
        blocked = null; // to release it
      }
    }, 2000); // run() after 2000 milliseconds
  }
} ///:~




The wait( ) inside Blocked.run( ) produces the blocked thread. When the Timer runs out, the object’s interrupt( ) method is called. Then the blocked reference is set to null so the garbage collector will clean it up (not necessary here, but important in a long-running program). Comentários (em inglês)

Thread groups



A thread group holds a collection of threads. The value of thread groups can be summed up by a quote from Joshua Bloch,[72] the software architect at Sun who fixed and greatly improved the Java collections library in JDK 1.2: Comentários (em inglês)



“Thread groups are best viewed as an unsuccessful experiment, and you may simply ignore their existence.”



If you’ve spent time and energy trying to figure out the value of thread groups (as I have), you may wonder why there was not some more official announcement from Sun on the topic, sooner than this (the same question could be asked about any number of other changes that have happened to Java over the years). The Nobel Laureate economist Joseph Stiglitz has a philosophy of life that would seem to apply here.[73] It’s called The Theory of Escalating Commitment: Comentários (em inglês)



"The cost of continuing mistakes is borne by others, while the cost of admitting mistakes is borne by yourself."



There is one tiny remaining use for thread groups. If a thread in the group throws an uncaught exception, ThreadGroup.uncaughtException( ) is invoked, which prints a stack trace to the standard error stream. If you want to modify this behavior, you must override this method. Comentários (em inglês)

Summary



It is vital to learn when to use concurrency and when to avoid it. The main reasons to use it are: to manage a number of tasks whose intermingling will make more efficient use of the computer (including the ability to transparently distribute the tasks across multiple CPUs), allow better code organization, or be more convenient for the user. The classic example of resource balancing is to use the CPU during I/O waits. The classic example of user convenience is to monitor a “stop” button during long downloads. Comentários (em inglês)



An additional advantage to threads is that they provide “light” execution context switches (on the order of 100 instructions) rather than “heavy” process context switches (thousands of instructions). Since all threads in a given process share the same memory space, a light context switch changes only program execution and local variables. A process change –the heavy context switch—must exchange the full memory space. Comentários (em inglês)



The main drawbacks to multithreading are:

  1. Slowdown occurs while waiting for shared resources.
  2. Additional CPU overhead is required to manage threads.
  3. Unrewarded complexity arises from poor design decisions.
  4. Opportunities are created for pathologies such as starving, racing, deadlock, and livelock.
  5. Inconsistenciesoccur across platforms. For instance, while developing some of the examples for this book, I discovered race conditions that quickly appeared on some computers but that wouldn’t appear on others. If you developed a program on the latter, you might get badly surprised when you distribute it.


One of the biggest difficulties with threads occurs because more than one thread might be sharing a resource—such as the memory in an object—and you must make sure that multiple threads don’t try to read and change that resource at the same time. This requires judicious use of the synchronized keyword, which is an essential tool, but must be understood thoroughly because it can quietly introduce deadlock situations. Comentários (em inglês)



In addition, there’s a certain art to the application of threads. Java is designed to allow you to create as many objects as you need to solve your problem—at least in theory. (Creating millions of objects for an engineering finite-element analysis, for example, might not be practical in Java.) However, it seems that there is an upper bound to the number of threads you’ll want to create, because at some number, threads seem to become balky. This critical point can be hard to detect, and will often depend on the OS and JVM; it could be less than a hundred or in the thousands. As you often create only a handful of threads to solve a problem, this is typically not much of a limit; yet in a more general design it becomes a constraint. Comentários (em inglês)



A significant nonintuitive issue in threading is that, because of thread scheduling, you can typically make your applications run faster by inserting calls to yield( ) or even sleep( ) inside run( )’s main loop. This definitely makes it feel like an art, in particular when the longer delays seem to speed up performance. The reason this happens is that shorter delays can cause the end-of-sleep( ) scheduler interrupt to happen before the running thread is ready to go to sleep, forcing the scheduler to stop it and restart it later so it can finish what it was doing and then go to sleep. The extra context switches can end up slowing things down, and the use of yield( ) or sleep( ) may prevent the extra switches. It takes extra thought to realize how messy things can get. Comentários (em inglês)



For more advanced discussions of threading, see Concurrent Programming in Java, 2nd Edition, by Doug Lea, Addison-Wesley, 2000. Comentários (em inglês)

Exercises



Solutions to selected exercises can be found in the electronic document The Thinking in Java Annotated Solution Guide, available for a small fee from www.BruceEckel.com.

  1. Inherit a class from Thread and override the run( ) method. Inside run( ), print a message, and then call sleep( ). Repeat this three times, then return from run( ). Put a start-up message in the constructor and override finalize( ) to print a shut-down message. Make a separate thread class that calls System.gc( ) and System.runFinalization( ) inside run( ), printing a message as it does so. Make several thread objects of both types and run them to see what happens. Feedback
  2. Experiment with different sleep times in Daemons.java to see what happens. Feedback
  3. In Chapter 8, locate the GreenhouseController.java example, which consists of four files. In Event.java, the class Event is based on watching the time. Change Event so that it is a Thread, and change the rest of the design so that it works with this new Thread-based Event. Feedback
  4. Modify the previous exercise so that the java.util.Timer class is used to run the system. Feedback
  5. Modify SimpleThread.java so that all the threads are daemon threads and verify that the program ends as soon as main( ) is able to exit. Feedback
  6. Demonstrate that java.util.Timer scales to large numbers by creating a program that generates many Timer objects that perform some simple task when the timeout completes (if you want to get fancy, you can jump forward to the “Windows and Applets” chapter and use the Timer objects to draw pixels on the screen, but printing to the console is sufficient).
  7. Demonstrate that a synchronized method in a class can call a second synchronized method in the same class, which can then call a third synchronized method in the same class. Create a separate Thread object that invokes the first synchronized method.
  8. Create two Thread subclasses, one with a run( ) that starts up and then calls wait( ). The other class’s run( ) should capture the reference of the first Thread object. Its run( ) should call notifyAll( ) for the first thread after some number of seconds have passed so that first thread can print a message. Feedback
  9. Create an example of a “busy wait.” One thread sleeps for awhile and then sets a flag to true. The second thread watches that flag inside a while loop (this is the “busy wait”) and when the flag becomes true, sets it back to false and reports the change to the console. Note how much wasted time the program spends inside the “busy wait” and create a second version of the program that uses wait( ) instead of the “busy wait.”
  10. Modify Restaurant.java to use notifyAll( ) and observe any difference in behavior.
  11. Modify Restaurant.java so that there are multiple WaitPersons, and indicate which one gets each Order.
  12. Modify Restaurant.java so that multiple WaitPersons generate order requests to multiple Chefs, who produce orders and notify the WaitPerson who generated the request. You’ll need to use queues for both incoming order requests and outgoing orders.
  13. Modify the previous exercise to add Customer objects that are also threads. The Customers will place order requests with WaitPersons, who give the requests to the Chefs, who fulfill the orders and notify the appropriate WaitPerson, who gives it to the appropriate Customer.
  14. Modify PipedIO.java so that Sender reads and sends lines from a text file.
  15. Change DiningPhilosophers.java so that the philosophers just pick the next available chopstick (when a philosopher is done with their chopsticks, they drop them into a bin. When a philosopher wants to eat, they take the next two available chopsticks from the bin). Does this eliminate the possibility of deadlock? Can you re-introduce deadlock by simply reducing the number of available chopsticks?
  16. Inherit a class from java.util.Timer and implement the requestStop( ) method as in Stopping.java.
  17. Modify SimpleThread.java so that all threads receive an interrupt( ) before they are completed.
  18. Solve a single producer, single consumer problem using wait( ) and notify( ). The producer must not overflow the receiver's buffer, which can happen if the producer is faster than the consumer. If the consumer is faster than the producer, then it must not read the same data more than once. Do not assume anything about the relative speeds of the producer or consumer.



[68] Runnable was in Java 1.0, while inner classes were not introduced until Java 1.1, which may partially account for the existence of Runnable. Also, traditional multithreading architectures focused on a function to be run rather than an object. My preference is always to inherit from Thread if I can; it seems cleaner and more flexible to me.



[69] Some examples were developed on a dual-processor Win2K machine that would immediately show collisions. However, the same example run on single-processor machines might run for extended periods without demonstrating a collision—this is the kind of scary behavior that makes multithreading difficult. You can imagine developing on a single-processor machine and thinking that your code is thread safe, then discovering breakages as soon as it’s moved to a multiprocessor machine.



[70] Inspired by Joshua Bloch’s Effective Java, Addison-Wesley 2001, page 190.



[71] See Design Patterns, by Gamma et. al., Addison-Wesley 1995.



[72] Effective Java, by Joshua Bloch, Addison-Wesley 2001, page 211.



[73] And in a number of other places throughout the experience of Java. Well, why stop there?—I’ve consulted on more than a few projects where this has applied.


Anterior Próximo Página Inicial Índice Conteúdo