Thread

Você nunca saberá a ordem em que as Threads serão executadas, tudo depende da implementação da VM… Como diz o livro da Kathy Sierra (SCJP) quando trata-se the Threads há poucas garantias.

Você nunca pode ter certeza que as theads vão rodar bonitinhas, uma a cada "Thread.sleep(100); "

Só com semáforo que eu consigo fazer isso: uma váriavel que diz de quem é a vez de “imprimir”.

Você pode sim controlar a ordem das Threads nesse caso.

Utilize um esquema de wait() e notify(). Dê uma pesquisada por aí que você vai encontrar bons exemplos.

hehehe Ué, e isto não é um semáforo??

semáforo?? tecnicamente seria assim mesmo? ou isso e uma giria popular que damos a algum tipo de POG??

O esquema é o mesmo.

Acontece que eu falei de wait e notify, que é a mais comum. Mas há a classe java.util.concurrent.Semaphore (que também é um tipo válido de solução). Outra solução válida seria a utilização de travas explícitas.

teitei, semáforo é sério mesmo hahahahahah

Tem em qualquer livro de Sistemas Operacionais, acho que foi até o Dijkstra que o definiu.

cesarherrera:

Você nunca saberá a ordem em que as Threads serão executadas, tudo depende da implementação da VM…

Não é da implementação da VM, mas sim do SO. A VM delega o escalonamento para o SO.

Nesse sentido, prefiro dizer que não há absolutamente nenhuma garantia…

Teitei, o que você deve ter em mente é que um bom SO vai tentar escalonar essas threads estatisticamente em 50% do tempo para cada uma. Como ele faz isso é a cargo dele. Um mal SO não vai ser tão justo assim.

felipealbuquerque:

Você pode sim controlar a ordem das Threads nesse caso. Utilize um esquema de wait() e notify(). Dê uma pesquisada por aí que você vai encontrar bons exemplos.

Só tem um cuidado aí.

Nesse caso as threads percorrem objetos diferentes, por isso, só usar os métodos com modificador synchronized, wait e notify não adiantaria.

Para que ele pudesse usar wait e notify ele teria que fazer o seguinte:
1. Criar um objeto compartilhado por ambas as threads e usar o synchronized, wait e notify nesse objeto (nada mais é do que usar um lock explícito. Poderia fazer isso compatilhando um objeto da classe Lock também.);
2. Usar as duas threads sobre o mesmo Runnable;

Esse é um erro que pega muita gente que está começando com threads.

É claro que controlar as threads dessa forma seria estúpido. Se você quer rodar um método seguido de outro, é melhor criar os dois runnables e fazer assim:

Run run1 = new Run();
Run run2 = new Run();

Thread t = new Thread() {
   @Override
   public void run() {
        run1.run();
        run2.run();
   }
}

t.start();

Isso ainda poupa recursos do SO, pois não é de graça criar e manter threads.