2012-06-25 5 views
4

Est-il possible en Java (Android) d'implémenter une version personnalisée d'un thread qui porte ses propres états?Fil avec des états personnalisés

Ce que je veux dire est: Alors que ThreadA est en état en marche, il peut encore être interrogé par ThreadB qui demande son état

e.g. 
ThreadA.getState(); 

Il est possible de modifier les valeurs des états à certains ones personnalisés? De manière à mettre en place une sorte de système de communication de base entre ces deux threads?

Merci.

+1

Simplement sous-classe 'Thread' et fournissez vos propres états. – user1329572

Répondre

5

Oui, c'est possible. Je l'ai beaucoup utilisé dans mes projets précédents, tout ce dont vous avez besoin est d'étendre la classe Thread.

public class StateThread extends Thread{ 
    String state = "ThreadState"; 
    public synchronized void setState(String newState){ 
     state = newState; 
    } 
    public synchronized String getState(){ 
     return state; 
    } 
    @override 
    public void run(){ 
     // Do stuff and update state... 
    } 
} 
+0

Merci, Java est en effet très puissant – 2dvisio

1

Threads état est maintenu par la machine virtuelle. VM utilise l'état pour surveiller et gérer le thread réel.

C'est pourquoi il n'y a aucun mécanisme pour modifier l'état du fil. Il n'y a pas de fonction setState qui permet de définir votre état personnalisé. Pour votre application, vous pouvez définir vos propres variables d'instance en étendant Thread mais cela ne peut en aucun cas modifier l'état de Thread.

2

Oui, il est possible d'effectuer cette tâche.
Est-ce un bon design? Je ne pense pas.
Il existe d'autres moyens pour effectuer la communication entre les threads -
Par exemple, vous devez utiliser une file d'attente avec un modèle Producteur/Consommateur. Je suis sûr qu'Android, comme JavaSE supporte le thread local - vous pouvez l'utiliser pour gérer les données locales (y compris les états) (peut-être en combinaison avec une file d'attente qui aura des "opérations" pour changer l'état géré par un thread
Si vous décidez d'opter pour la solution d'avoir des méthodes de setstate et getState, au moins envisager d'utiliser le ReaderWriterLock pour optimiser votre verrouillage

+0

+1 pour suggérer quelque chose qui pourrait valoir la peine. La vérification directe d'un objet 'state' partagé n'est pas efficace car le thread vérifié n'a rien à faire.J'utilise cette approche sur les travaux intégrés - un objet d'état est passé autour de chaque thread dans sa file d'attente d'entrée «normale» ou autre, et doit être renvoyé au thread «LED-blink» de basse priorité dans les 10 secondes. Si l'objet ne revient pas, la DEL cesse de clignoter et le minuteur de surveillance matériel n'est pas actualisé. Cela détecte les threads bloqués ou en boucle (un seul cœur, donc une boucle arrête le thread clignotant). –

1

Synchronisation avec des données partagées ne sont pas très utiles pour déterminer le « état » d'un fil - le thread écrit son état comme 'sain', puis reste bloqué - le thread du moniteur vérifie alors l'état et le trouve sain. l''état' devrait signifier que le thread vérifié fait quelque chose, pas seulement regarder directement un objet partagé. Si vous avez un design de passage de message, (comme suggéré par zaske), vous pouvez passer un 'state record' dans la file d'entrée d'un thread, lui demander d'enregistrer son état à l'intérieur et de le transmettre au fil suivant. Le thread 'monitor' attend que l'enregistrement revienne, tout est rempli. S'il ne l'obtient pas dans un délai raisonnable, il peut enregistrer ce qu'il a - il garde une référence à l'objet d'enregistrement d'état, afin qu'il puisse voir quel thread n'a pas mis à jour son état. Il pourrait, peut-être, ne pas nourrir un chien de garde.

Questions connexes