Questão Thread

Imprime 7, agora vou compilar.

isso é inderteminado …
pq qdo vc chama o start(), a thread passa do estado NOVO para o de PRONTO PARA EXECUCAO … mas naum quer dizer q ele vai entrar diretamente em EXECUCAO … e em outra linha … vai estar sendo processado … a thread MAIN. … q tem na pilha de execucao o metodo foo … entao …
vc naum sabe o exato momento que a thread vai imprimir data… e o seu valor

“Quando se trata de threads, pouca coisa é garantida.”

sinto informar nobres amigos, mas nenhum acertou! :lol: :lol:,
DICA: nessa thread da pra garantir o resultado sim!

PQ!??! Eu respondi no outro topico falando q nao dava pra garantir, mas pq q da pra garantir!?!?

cara da pra garantir q sempre é 123, visto q o start method e o foo() são synchronized. por isso o codigo:

data = 100; 
        data += 20; 
        data += 3;

sempre sera executado antes q a thread starte realmente

Realmente, o método foo() é SYNCHRONIZED !!!
sendo assim já podemos garantir que o run só será executado,
ao término de foo() !!!
Boa questão!

Só pro causa de serem métodos sincronizados???

Compilei assim …

public  void foo() {

        start();
        data = 100;
        data += 20;
        data += 3;

    }

    public  void run() {

        System.out.println(data);

    }

rodei 200 vezes e resultou em duzentos “123” (?)

O que estou fazendo errado?

spier

Só pro causa de serem métodos sincronizados???

Compilei assim …

public  void foo() {

        start();
        data = 100;
        data += 20;
        data += 3;

    }

    public  void run() {

        System.out.println(data);

    }

rodei 200 vezes e resultou em duzentos “123” (?)

O que estou fazendo errado?

spier

Entenda: o fato de ter rodado essa thread sem metodos sinchronized n implica q vc tera resulatados diferentes. essa sua forma de testar garantias de thread n é muito eficiente, da forma q ta n garante q sempre sera impresso 123, vai depender da gerencia do escalonador, e o mesmo pode tomar , nesse caso, “sempre” a mesma atitude em uma amostra pequena, mas impossivel de garantirmos com 100% de certeza.

deu pra entender?

Não, não, … note que tirei syncronized dos métodos e continuou “perfeitamente” sincronizado!

Reconheço que o que fiz não foi nem um pouco científico - rodando sem concorrência de threads, por exemplo, mas do jeito que fiz, não deveria ter uma ocorrência, minima talvez, indeterminada?

(É só para desenferrujar meu Java )

spier

“spier”:

Não, não, … note que tirei syncronized dos métodos e continuou “perfeitamente” sincronizado!

Reconheço que o que fiz não foi nem um pouco científico - rodando sem concorrência de threads, por exemplo, mas do jeito que fiz, não deveria ter uma ocorrência, minima talvez, indeterminada?

(É só para desenferrujar meu Java )

spier

insisto em dizer: OS METODOS N ESTAO SINCRONIZADOS NO SEU EXEMPLO, muito menos PERFEITAMENTE

se vc tentar executar varias vezes em um outro computador, com clock diferente e q esteja super “pesado” de processos, por exemplo. podera da outro valor, mas nada é garantido!!! :???:

Exato mestre fabao ou fofao !!!

Vc tem toda a razao… nao eh garantido se vc tirar o synchronized…

spier execute novamente seu exemplo, agora forcando uma demora no processamento da thread main…
altere seu metodo foo para:

public  void foo() {

        start();
        data = 100;
         //Aqui vc esta colocando a thread que esta rodando este 
         //metodo na pilha para durmir.... 
         //assim vai dar tempo da outra thread criada imprimir a data!!!  
         try{
             Thread.sleep(2000);
         }catch(InterruptedException e){}
        data += 20;
        data += 3;

    }

OK, como coloquei, estou desenferrujando… :oops: :???:

spier

guga (fmartins), obrigado pelo “mestre”, ehhe

“spier”:

OK, como coloquei, estou desenferrujando… :oops: :???:

spier

spier, n estamos discutindo ou algo assim, queremos q vc entenda! ta blz isso ai? quero dizer: vc entendeu e aceitou?

ps.: entender é bem diferente de aceitar :lol: