mais uma questão do exame sobre threads

Acabei de lembrar de mais uma questão (que eu acertei!):

public class SyncTest {

private int x;
private int y;
private synchronized viod setX( int i ) { x =1 ;}
private synchronized viod setY( int i ) { y =1 ;}

public void setXY ( int i ) { setX(i); setY(i);}

public synchronized boolean check() { return x!=y ; }

}

Under which conditions will check() return 'true' when called from a different class ?

a) check() can never return true
b) check() can return true when setXY is called by multiple threads
c) check() can return true when multiple threads call setX & setY seperately
d) check() can only return true if SyncTest is changed to allow x & y to be set seperately.

Não so nenhum perito em threads e não sei se entendi bem a questão, mas a resposta seria a -> d

x e y não foram inicializados (são automaticamente) então pode haver algum momento que x e y ainda são iguais a 0 e depois inicializados com 1 pelos métodos setX() e setY().
setXY() é pública, várias linhas podem acessar ao mesmo tempo e haverá a possibilidade do retorno ser true.
(estou certo?)

a resposta D está errada!

Tente novamente...

imaginei... preciso estudar mais threads

Debugger Membro desde: 05/12/2003 10:46:16 Mensagens: 57 Offline

A Resposta certa seria a "b" ? Porque como o metodo setXY não é synchronized e apenas os metodos setX e setY são teriamos o seguinte cenario:

Duas Threads chamam o método setXY... a primeira a chamar vai entrar no setX e setar o valor de x em 1.... a outra vai ficar esperando o metodo ser liberado.. quando ele for liberado a primeira thread vai chamar o setY e setar 1, enquanto a segunda thread vai chamar o setX e setar 2... nesse momento se uma terceira thread chamar o check() ele vai retornar true, pq o x é 2 e o y é 1...

Eu acho que seria B e C... pois é o método que eh synchronized, entao ele pode finalizer o setX e o outro obter o lock pra setY, deixando diferente... Assim como o setXY nao eh synchronized, pode ser q duas thread alterem ao mesmo tempo um e outro, deixando diferente tb....

[editado] Retirem a C: métodos privados

[/editado]

Am i right?

B.

Exatamente!
A correta é B porque setXY() não é sincronizado.

No Core Java há um parágrafo que diz que um método deve SEMPRE chamar sleep() para dar chance a outra linha de execução. Pelo que sempre ouvi falar duas linhas podem executar o mesmo método (senão synchronized não teria propósito).
sleep() seria apenas para dar mais uma chance para outra linha?

Se eu nao to enganado, o método yeld tb o faz.... yeld() abre mao do processo atual para dar chance a outro, mas nao pára, apenas volta ao estado de "proximo a executar"....
O sleep() volta pra inativo durante N milisegundos. Ateh q seu tempo acabe e ele disperte, entrando entao na fila para ser executado.

Só que o sleep() não libera o lock do objeto, daí não vai dar a vez para outra thread.
wait() seria similar ao sleep() com a diferença de liberar o lock do objeto.

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