È possibile sapere se un processo è in attesa in stato bloccato su una chiamata di ricezione () su Linux?

Question

Il mio scopo principale è quello di eseguire i processi uno a uno in modo round robin fino a quando uno chiama di ricezione () e viene bloccato, in modo che l'esecuzione passi al processo successivo nella coda. Esiste un'applicazione controller codificata in Java che esegue questi processi (che sono anche applicazioni Java) utilizzando Runtime.getRuntime (). Exec () e mantiene i valori di ritorno che sono oggetti Process.

Per raggiungere questo scopo, ho bisogno di catturare le chiamate di ricezione () (o il loro stato, che è bloccato) e dirle all'applicazione controller (master).

Se possibile, posso passare al livello più basso che vuoi. Il mio primo pensiero è stato quello di ottenere queste informazioni dal driver e poi dirle all'applicazione Java del mio controller. Ho scritto un modulo di rete del kernel linux che cattura le operazioni di invio e ricezione, ma AFAIK la funzione socket.receive () non dice nulla al driver di rete.

Quindi, penso che le opzioni siano ottenere queste informazioni dalla JVM, in qualche modo ottenerle da un comando di Linux o così, o forse attraverso il modulo del kernel di Linux?

Quali sono i tuoi suggerimenti?

Answer 1

Se vuoi sapere se i tuoi thread sono bloccati, o esattamente su cosa sono bloccati, puoi prendere un dump del thread o usare uno strumento come jvisualvm per collegarsi al processo e dare un'occhiata (in jvisualvm dovresti collegarti al processo, prendere una discarica di thread e quindi guarda l'attività di ogni thread).

Answer 2

Hai guardato systemtap ? Dovrebbe essere prontamente disponibile sui recenti sistemi Fedora.

Best Anders

Answer 3

Non so se questo ti aiuterà, ma potresti ottenere informazioni sullo stato di un thread Java sul tuo computer usando l'attacco locale.

1) Aggiungi tools.jar al tuo percorso di classe e usa VirtualMachine.list () per ottenere un elenco della JVM in esecuzione sul tuo computer.

2) Collega alla JVM elaborata utilizzando VirtualMachine.attach (virtualMachineDescriptor)

3) Ottieni l'indirizzo del connettore locale, vm.getAgentProperties (). get (" com.sun.management.jmxremote.localConnectorAddress ");

4) Utilizzare JMXConnectorFactory.newJMXConnector (...) per connettersi alla JVM

5) Dalla connessione JMX cercare ThreadMXBean

6) Da ThreadMXBean si ottiene una matrice di ThreadInfos che descrive tutti i thread nella JVM.

7) Da TheadInfo # getThreadState () è possibile verificare se lo stato è ThreadState.BLOCKED

Answer 4

È necessario utilizzare le primitive di comunicazione tra processi nei processi di lavoro per informare l'applicazione del controller che sono pronti a ricevere dati.

Non puoi fare ipotesi su come i processi figlio implementano la lettura del loro socket. Potrebbero utilizzare recv, oppure selezionare, oppure poll, ecc., Per attendere i dati di rete.

Answer 5

In realtà ci sono alcuni punti qui. Lo scheduler di Linux è abbastanza intelligente da prevenire un'attività bloccata. Vale a dire, se chiami la ricezione () e non c'è nulla in attesa di ricevere, la tua attività verrà probabilmente messa in pausa fino a quando la chiamata tornerà. Non è necessario gestire la pianificazione; il kernel Linux lo farà per te.

Detto questo, se hai bisogno di sapere se la tua attività è bloccata da qualche applicazione demone, se sei disposto a scrivere un LKM, perché non ottenere semplicemente l'attività nell'elenco delle attività che ti interessa e controllare il suo stato?

Ovviamente, il semplice controllo dello stato dell'attività potrebbe non dirti esattamente quello che vuoi. Se lo stato della tua attività è TASK_INTERRUPTIBLE , ti dice solo che la tua attività è in attesa di qualcosa , ma potrebbe non essere una cosa banale capire cosa sia quel qualcosa. Allo stesso modo, l'attività può trovarsi in uno stato TASK_RUNNING e non essere effettivamente in esecuzione sulla CPU al momento attuale (ma, almeno, nello stato TASK_RUNNING conosci la tua attività non è bloccato).

Answer 6

Puoi semplicemente inviare un segnale QUIT (Ctrl- \ sulla console) per ottenere un dump del thread.