O livro de Java que usei para aprender Threads sempre colocava o método signal() como a última instrução do método. Nunca foi dito o porquê (apesar de imaginar). Ao estudar o livro do Tanenbaum, Sistemas Operacionais, ele diz que o método signal() obriga que o processo saia imediatamente do monitor (além de outras coisa, claro).
O método signal() obriga a saída do processo da região crítica, imediatamente?
Por signal vc quer dizer o notify(), não?
No caso do Java, o sinal é enviado apenas quando a thread libera o lock, como era de se esperar. Isso está inclusive descrito no javadoc:
[quote=ViniGodoy]Por signal vc quer dizer o notify(), não?
No caso do Java, o sinal é enviado apenas quando a thread libera o lock, como era de se esperar. Isso está inclusive descrito no javadoc:
Não, estou falando do método signal() mesmo. Quando criamos um objeto Lock através de um ReentrantLock(), o usamos para criar uma área de exclusão mútua.
Se um objeto entra no espaço de endereçamento compartilhado, mas não pode continuar por qualquer motivo, chamamos o método await() em algum Condition para que a thread em poder do lock a libere. Essa thread irá para o estado de bloqueado. Uma outra thread deverá chamar o método signal() ou signalAll() para que a thread bloqueada possa competir novamente pela CPU.
No caso, sempre colocamos o método signal() como a última instrução do método. Não tinha lido isso antes, mas já imaginava. Tanenbaum diz que o método signal() (não do Java, mas o método signal de monitores. Ele fala desse método de maneira geral) obriga a thread que possui o bloqueio a sair da área de exclusão mútua imediatamente. Queria saber se no Java também se aplica.
O método signal(), no Java, faz com que a thread deixe imediatamente a área de exclusão mútua?