O parametro do sleep é em milisegundos. Assim fico com a 2, apesar da duvida entre a 1 e a 2. Pois em um sistema operacional que nao usa divisão de tempo nao podemos garantir que este thread irá “dormir” por 1,5 segundos.
[]s, Welington B. Souza
balrog
o esquema é o seguinte:
após o sleep ter ficado dormindo 1,5 segundos, quando o scheduler retoma a thread, não significa que ela seja executada imediatamente, por isso que a 2 é a resposta correta, ele pode ficar 1.5 segundos ou mais
e claro, o que vc disse tbm faz sentido no que diz respeito aos sistemas operacionais terem dua parcela de influencia na maneira como as threads são tratadas
[]s
wbsouza
Tem razão
Outro aspecto importante a ser observado é que em um ambiente multithread (várias linhas de execução), quando temos dois threads “acordando” ao mesmo tempo. Daí eles vão “disputar” a cpu para iniciar a execução. Daí o thread que teoricamente iria ficar parado 1,5 segundos, terá a sua execução retardada, pois ficou na fila esperando o thread que “pegou” a cpu primeiro.
[]s, Welington B. Souza
T
tanque
Acho muito sacanagem a SUN colocar esse tipo de pergunta capiciosa. Eh perfeitamente possivel (mas nao desejavel) que a thread fique, digamos 15 segundos, apos esse sleep, sem retomar a CPU. Basta que o sistema operacional decida isso, digamos, por exigencia de outros processos, de outros usuarios.
Mas acredito que mesmo assim, eh tranquilo passar na prova.
P
Panga
acho q naum é por isso naum, qnd a thread sai do sleep ela vai diretamente para ready. Isto é “How many seconds will the thread be in the sleeping state”, mesmo q a thread naum seja executada imediatamente, ela naum estará mais em slleping. A resposta certa realmente é a “2”, mas porque por definição o valor do parâmetro em milisegundos é um valor aproximado.
wbsouza
Se vc usa um sistema Operacional que não usa divisão de tempo (ex: Solaris usa algoritimo Round Robin por default) e se tem uma thread que usa a CPU direto sem fazer sleep ou um objeto chame wait para pará-la, a primeira thread não terá a oportunidade sequer de mudar o “sleep state”, pois a CPU “se tornou” escrava da primeira thread.