métodos syncronized

Pessoal, seguinte, se eu tenho vários threads acessando um método syncronized.
Quando algum thread em execução obtêm o acesso ao método, ele é bloqueado ao thread atual, de forma que os outros não o podem acessar, correto?
Minha dúvida é se isso sempre ocorre assim? Existe alguma exceção para dois threads acessarem um método syncronized??
Se o thread obtiver o bloqueio e for suspenso, tipo, por um sleep, ou yield, os outros threads obtem acesso ao método?? independente do tempo q este ficou suspenso?? ou nada é garantido??

O acesso ao método só é liberado (ser for sync) assim que o método que possui o acesso, terminar de executa-lo.

sleep() não libera o lock do objeto, já o wait() sim.

yield() passa a vez para outra thread, mas não é garantido que funcione desta maneira pois é a JVM que escolhe qual thread vai executar, portanto uma thread pode ficar executando infinitamente mesmo chamando yield().

Ao invés da JVM, não é o SO quem escolhe?

Ok Ana, então com sleep() as outras threads não obtêm lock ao objeto, e sim com wait().

Agora, não entendi. Quando eu chamo yield para uma thread que está em um metodo sync, depende da JVM se ela vai liberar o lock ou não ?? isso mesmo ??

o yield(), não e mais ou menos assim, da um sleep() na thread se tiver algum Thread na espera da chave, caso não tenha ele continua executando?

Pera...
Vc chama um método sync DENTRO de uma Thread.. e nao o controario

Qdo vc chamou um método que eh sync de uma thread A, e, enquanto A executa esse método, vc atravez da thread B chama o mesmo método, B espera A terminar para começar. Ok situação pronta.

dar sleep dentro de A, nao faz com que seja liberado para B, portanto B contiar esperar A temrinar.

dar yield nao garante que B seja a proxima a ser chamado.

dar wait libera o método para B, deixando A aguardando que alguem dispare um notify para continuar.

Acho que é isso.. correções por favor

elvishr wrote:Ok Ana, então com sleep() as outras threads não obtêm lock ao objeto, e sim com wait().

Agora, não entendi. Quando eu chamo yield para uma thread que está em um metodo sync, depende da JVM se ela vai liberar o lock ou não ?? isso mesmo ??

Com relação a yield(), quando uma thread o chama, simplesmente pára de executar e volta para a fila, com isso acredito que o lock é liberado senão não teria sentido. Mas isso eu não tenho certeza, não, estou supondo.
O que sei sobre yield() é que ele é uma maneira de não deixar uma thread só ficar rodando o tempo todo e dar chance para as outras, só que isso depende da JVM e pode ou não depender das prioridades que elas têm, mas nada é garantido.

eu lembro de ter estudado chamando yield() de fora de um método sync... Agora chamando de dentro de um método sync num tenho a menor ideia do que acontece...rssss...

phstc wrote:o yield(), não e mais ou menos assim, da um sleep() na thread se tiver algum Thread na espera da chave, caso não tenha ele continua executando?

É... não se dá um sleep() numa thread...

Não vi em lugar algum dizendo que yield() chama sleep(), não.

A thread que chamou yield() pára de executar e vai para o estado de runnable esperando por sua vez na fila.
Daí, entre todas que estão em runnable, uma é escolhida para executar e pode ser a mesma.
Mas isso não tem a ver com locks, mesmo porque quando um lock é liberado não é garantido que uma thread que está esperando por ele vai executar imediatamente.

brlima wrote:eu lembro de ter estudado chamando yield() de fora de um método sync... Agora chamando de dentro de um método sync num tenho a menor ideia do que acontece...rssss...

Também não vi isso, seria meio estranho e acredito que esse tipo de coisa não cai no exame.

ana_abrantes wrote:Com relação a yield(), quando uma thread o chama, simplesmente pára de executar e volta para a fila, com isso acredito que o lock é liberado senão não teria sentido. Mas isso eu não tenho certeza, não, estou supondo.

Estava com essa duvida tambem - o unico metodo que libera os locks eh o wait... yield, sleep, join e mesmo o notify mantem os locks.

Marcio Kuchma

danieldestro wrote:Ao invés da JVM, não é o SO quem escolhe?

Uhm... ao que aprece, a JVM implementa umas Threads virtuais [o Gosling disse na ACM Queue que eles tiveram problemas com mais de 10.000 threads] , então acho que é a JVM mesmo...

[]s

Notícias, artigos e o maior fórum brasileiro sobre Java