[Thread et files d'attente]Problème de compréhension

Bonjour, j'ai un problème pour comprendre cette exemple d'utilisation des files d'attente dans Python. Voilà le code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

import threading, Queue   class InterfaceExterne(threading.Thread): def __init__(self, externalCallable, **kwds): threading.Thread.__init__(self, **kwds) self.setDaemon(1) self.externalCallable = externalCallable self.workRequestQueue=Queue.Queue() self.resultQueue = Queue.Queue() self.start() def request(self, *args, **kwds): "Appelee par les autres threads comme le serait externalCallable" self.workrequestQueue.put((args,kwds)) return self.resultQueue.get() def run(self): while 1: try : arg, kwd = self.worRequestQueue.get_nowait() except Queue.Empty : pass else : self.resultQueue.put(self.externalCallable(*args, **kwds))

---

En fait, je n'arrive pas à comprendre le déroulement des opérations :
Par exemple, si je charge ce fichier dans l'interpréteur et que je réalise les opérations suivantes :

Code:

---

1 2 3 4 5 6 7

def dire_bonjour_a(nom): print 'bonjour' + str(nom) return 'j\'ai dit bonjour'   thread_bonjour = InterfaceExterne(dire_bonjour_a) thread_bonjour.request('monde')

---

Quand un appel à thread_bonjour.request('monde') est fait, j'ai du mal à comprendre comment la file d'attente va fonctionner, parce que je ne comprends pas comment la méthode self.request() peut retourner un résultat si la méthode run() n'a pas pris connaissance de la requête. Pouvez-vous m'expliquer comment cela fonctionne ?

Bonjour,

Le thread ne fonctionne effectivement que lorsque la méthode run() est lancée, et jusqu'à ce qu'elle s'arrête.

Or, la méthode run est lancée ici avec la méthode start(), elle-même lancée à l'initialisation de la classe.

Donc, il suffit d'instancier ta classe pour que le thread soit actif. Tu peux d'ailleurs le vérifier avec la méthode .isAlive().

Tyrtamos

Bonjour,

start est appelée dans l'init, ce qui a pour effet de lancer run dans un autre thread. run regarde en permanence dans la queue s'il y a quelque chose pour lui (ce qui a pour effet de consommer tout le CPU, d'ailleur. Pourquoi pas get plutot que get_nowait?)
De son coté, la méthode request place quelquechose sur la queue request puis arrive a l'appelle de get(), ce qui a pour effet de la bloquer jusqu'à ce qu'il y ait quelquechose dans la queue result.
Pendant ce temps, le get_nowait de la queue request retourne quelque chose, le calcul est fait et le tout est mis dans la queue de result (resultqueue.put...).
Du coup le get() de la méthode request() se débloque, et il retourne le résultat.

J'espère que ça clarifie??

Oui, merci beaucoup. En fait, je n'avais pas réalisé (juste ce matin en lisant le bouquin) que la méthode un_thread.run() lancée par la méthode un_thread.start() est contenue dans un thread à part, complétement séparé des autres méthodes.

Citation:

---

pourquoi get_nowait et pas get

---

: c'est une modification personnelle de l'exemple du bouquin due à ma mauvaise compréhension, alors qu'un bon timeout de 2 secondes permettrait d'économiser du temps processeur, c'est noté.

En fait, en attendant, j'ai décidé d'utiliser un sémaphore.
(D'ailleurs je me demande si je devrais réécrire mon application :?, maintenant qu'elle marche tant bien que mal)

Schématiquement, j'ai deux méthodes, lecture() et ecriture(), et je ne veux pas que les deux interfèrent. Je fais alors :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class Device: def __init__(self): self.mon_semaphore=threading.BoundedSemaphore(1) #suite de l'initialisation   def lecture(self,param): self.mon_semaphore.accquire() #operations de lecture self.mon_semaphore.release()   def ecriture(self,param): self.mon_semaphore.acquire() #operation d'ecriture self.mon_semaphore.release()

---

Ces methodes sont appelees depuis le thread principal et un autre thread externe qui fait une operation de lecture toutes les dix secondes.
Est-ce que cette méthode d'utilisation du sémaphore est correcte, du moment que mon_device=Device est bien une unique variable globale ?

C'est en effet l'idée. J'aurais utilisé un Lock ou RLock plutot qu'un Semaphore (RLock permettrait d'appeler Lecture depuis Ecriture par exemple), et puis j'aurais appelé release dans un bloc finally pour éviter de tout bloquer en cas d'erreur.