У меня есть класс, который создает объект Thread для генерации некоторых элементов в цикле и сохранения их в очереди. Псевдокод выглядит так:
class DetectionProcessor:
def __init__(self, detectionloader, queueSize = 1024):
'some initializer code'
self.Q = Queue(maxsize = queueSize)
def start(self):
t = Thread(target=self.update, args=())
t.daemon = True
t.start()
def update(self):
for i in range(self.datalen):
item = 'code to generate item'
while self.Q.full():
time.sleep(0.2)
self.Q.put(item)
def read(self):
return self.Q.get()
def len(self):
return self.Q.qsize()
В основной программе я также обращаюсь к элементам с помощью .get () в цикле
det_processor = DetectionProcessor(loader).start()
for i in im_names_desc:
with torch.no_grad():
item = det_processor.read()
То, что происходит, похоже на последние несколько итераций основного цикла det_processor.read()
зависает и дальше не будет. После прерывания времени выполнения я получаю следующую трассировку:
Обновление:
Я забыл упомянуть, что класс DetectionProcessor - не единственный класс, использующий классы многопоточности и очереди, но последний. Немного поигравшись с кодом, я понял, что на самом деле причина, по которой он зависает, заключается в том, что он вызывает get()
в другой очереди, которая пуста для последней пары итераций. Этого не должно быть, поскольку количество звонков get()
точно такое же, как и количество предметов в предыдущем классе