É possível saber se um processo está esperando no estado Bloqueado em um recebimento de chamadas () no Linux?

Question

O meu principal objetivo é executar processos, um por um em um modo round-robin até que um chamadas receber () e é bloqueado, de modo que a execução muda para o próximo processo na fila. Há uma aplicação de controlador que é codificado em Java e que executa estes processos (os quais são também aplicações Java) utilizando Runtime.getRuntime (). Exec () e mantém os valores de retorno, que são objectos de processo.

Para atingir este objectivo, eu preciso para capturar as chamadas receber () (ou seus estados, que é bloqueado) e dizer-lhes para a aplicação do controlador (master).

I pode ir tão baixo nível como você quer se isso é possível .. Meu primeiro pensamento foi para obter essa informação a partir do driver e, em seguida, dizer-lhe para meu controlador de aplicativo Java. Eu escrevi um módulo de rede do kernel linux que capta a enviar e receber operações, mas AFAIK a função socket.receive () não diz nada para o driver de rede.

Então, eu acho que as opções são para obter essa informação a partir de qualquer JVM, de alguma forma obtê-lo a partir de um comando linux ou mais, ou possivelmente através do Linux Kernel módulo?

O que são as suas sugestões?

Answer 1

Se você quer saber se os seus segmentos são bloqueados, ou exatamente o que eles estão bloqueados, você pode tomar um despejo de thread ou usar uma ferramenta como jvisualvm para anexar ao processo e dar uma olhada (em jvisualvm você anexar ao processo, tomar um despejo de thread , e depois olhar para a atividade de cada segmento).

Answer 2

Você olhou para systemtap ? Devem estar prontamente disponíveis em sistemas recentes do Fedora.

Melhor Anders

Answer 3

Eu não sei se isso vai ajudá-lo, mas você pode obter informações sobre o estado de uma thread Java em sua máquina usando locais anexar.

1) Adicione o tools.jar ao seu classpath e usar VirtualMachine.list () para obter uma lista da JVM rodando em sua máquina.

2) se ligam ao JVM processados ??usando VirtualMachine.attach (virtualMachineDescriptor)

3) Obter o endereço conector local, vm.getAgentProperties () get ( "com.sun.management.jmxremote.localConnectorAddress");.

4) Use JMXConnectorFactory.newJMXConnector (...) para se conectar à JVM

5) A partir da conexão JMX pesquisar o ThreadMXBean

6) A partir do ThreadMXBean você obter uma matriz de ThreadInfos que descreve os tópicos na JVM.

7) A partir TheadInfo # getThreadState () você pode verificar se o estado for ThreadState.BLOCKED

Answer 4

Você deve usar primitivas de comunicação entre processos em seus processos de trabalho para notificar o aplicativo controlador que eles estão prontos para receber dados.

Você não pode fazer suposições sobre como os processos filhos implementar a sua leitura socket. Eles poderiam estar usando recv, ou selecione, ou pesquisa, etc., para aguardar dados da rede.

Answer 5

Na verdade, existem alguns pontos aqui. O programador Linux é bastante inteligente para antecipar-se uma tarefa bloqueada. Ou seja, se você chamar receber () e não há nada à espera de receber, a sua tarefa será, provavelmente, colocar para dormir até o momento em que a chamada irá retornar. Você não precisa para lidar com a programação; o kernel Linux vai fazer isso por você.

Dito isso, se você precisa saber se sua tarefa é impedido de alguma aplicação daemon, se você estiver disposto a escrever um LKM, porque não basta obter a tarefa na lista de tarefas que você está interessado, e verificação seu estado?

Claro, basta verificar o estado da tarefa pode não lhe dizer exatamente o que você quer. Se o seu estado tarefa é TASK_INTERRUPTIBLE, só lhe diz que sua tarefa está esperando em alguma coisa, mas não pode ser uma questão trivial para descobrir que coisa é essa. Da mesma forma, sua tarefa pode estar em um estado TASK_RUNNING e na verdade não estar em execução no CPU no momento atual (mas, pelo menos, no estado TASK_RUNNING você sabe que sua tarefa não é bloqueado).

Answer 6

Você pode apenas enviar um sinal SAIR (Ctrl- \ no console) para obter um despejo de thread.