Sincronizando threads

Não se pode saber qual o bloco de que classe é executado primeiro esse é o ponto em usar Threads!!!

O que acontece é que se o o bloco do main for executado primeiro quando chegar a b.wait e vai parar e esperar que b o notifique. Se ele corre depois, quando chegar a b.wait ele já continua pq b não existe mais.

So uam dica. use notifyAll em vez de notify mesmo que supostamente so exista uma thread esperando.

Recomendo que use os novos objetos de java.concurrent sobretudo BlockingQueue e padrão de alto nivel como produtor-consumidor, em vez de se preocupar com Threads. Threads é legal mas é complicado. Tem um livro da O’Riley chamado Threads que recomendo bastante.

Então no método “main”, o bloco sincronizado é utilizado pela thread b, certo!!!
Que quer dizer que “b” obteve o bloqueio, mas bloqueio de que???
Da execução da classe???

Nesse ponto a thread “b” já esta em execução e quando ela finaliza, notifica a thread “main” que estão no seu poll de espera.

O bloco sincronizado não é usado pela Thread B e sim pela thread principal. A thread principal não é o objecto nem a classe ThreadA mas sim a thread que a JVM criou antes de chamar o main.

synchronized (b) não significa “sincroniza com b” ou “bloqueia b” significa “usa b para sincronizar a thread corrente” o fato de b ser um objeto Thread é irrelevante aqui. Poderia ser qualquer classe que herde de Object.

O bloco synchronized (this) dentro da Thread é irrelevante pq essa thread não cria outras threads com quem se sincronizar.

Para mandar correr uma thread e esperar que ela termine o comando certo é join e não wait. join é tipo especial de wait que espera que a thread termine em vez de esperar uma notificação.

Num ambiente multi-thread não ha bloqueio. Essa é a graça de usar várias Threads. O máximo que se pode fazer é fazer uma thread esperar por outra, mas é só.

Então a thread “main” utilizou o objeto “b” para bloquear a execução da thread corrente, que neste caso é a “main”.
Pelo fato de utilizar “b” para bloquear a thread em execução(main), só “b” poderá notificar a thread “main”!!!
Se a Thread “b” que esta sendo executada, não nofiticar sua(s) thread(s), “main” nunca mais sairá do estado executável.

Seria isso?

“heidermatos”:

Então a thread “main” utilizou o objeto “b” para bloquear a execução da thread corrente, que neste caso é a “main”.

sim

Só b pode ser usado para notificar a thread main. É diferente de so b poder notificar. Qualquer thread the tenha acesso a b pode usar b para notificar a thread main.

Se a Thread “b” que esta sendo executada, não nofiticar sua(s) thread(s), “main” nunca mais sairá do estado executável.

Seria isso?

Não é bem isso. Se b nunca for notificado, main nunca será liberanda. Mas não existe o conceito de “as suas threads”

Oque eu quiz dizer com “Suas Threads”, é que uma thread pode ter muitas outras em sua lista de espera.
Não neste exemplo, entendeu.
Por que “b” só pode possui uma em sua lista, que neste exemplo poderia ser a “main”.

Muito obrigado pelas explicações sergio.

“heidermatos”:

Oque eu quiz dizer com “Suas Threads”, é que uma thread pode ter muitas outras em sua lista de espera.
Não neste exemplo, entendeu.
Por que “b” só pode possui uma em sua lista, que neste exemplo poderia ser a “main”.

Muito obrigado pelas explicações sergio.

Na realidade é ao contrário. Qualquer objeto tem o método wait() portanto qualquer objeto pode ter uma coleção de listas esperando. É o objeto sincronizado , o que fica dentro de “sinchronize(x)” que mantém a lista de espera. A thread em si mesmo não mantém nenhuma informação sobre nenhuma outra thread. (exatamente por isso é preciso um objeto para fazer o sincronismos)

Isto eu sei, pelo fato de todas as classes extenderem de Object implicitamente.
No mais, muito obrigado!!!