Черга. Черга проти колекцій.deque

Мені потрібна черга, в яку можна покласти кілька потоків, і з яких можна прочитати кілька потоків.

У Python є щонайменше два класи черг, Queue.Queue і collection.deque, причому перший, здавалося б, використовує останній внутрішньо. Обидва заявляють, що захищені потоками в документації.

Однак у документах черги також зазначено:

collection.deque - це альтернативна реалізація необмежених черг з операціями швидкого атомного додавання () та popleft (), які не потребують блокування.

Я думаю, я не зовсім розумію: чи означає це, що врешті-решт деке не є повністю безпечним для потоків?

Якщо це так, я, можливо, не повністю розумію різницю між двома класами. Я бачу, що черга додає функцію блокування. З іншого боку, він втрачає деякі функції, такі як підтримка оператора.

Доступ до внутрішнього об'єкта deque безпосередньо, є

x у черзі (). deque

нитка-безпечна?

Крім того, чому черга використовує мьютекс для своїх операцій, коли deque вже захищений потоками?

Queue.Queueі collections.dequeслужать різним цілям. Queue.Queue призначений для того, щоб дозволяти різним потокам спілкуватися за допомогою повідомлень / даних у черзі, тоді як collections.dequeвін просто призначений як структура даних. Ось чому Queue.Queueє такі методи , як put_nowait(), get_nowait()і join(), в той час як collections.dequeне робить. Queue.Queueне призначений для використання як колекція, тому не вистачає подобань inоператора.

Це зводиться до цього: якщо у вас є кілька потоків і ви хочете, щоб вони могли спілкуватися без необхідності блокування, ви шукаєте Queue.Queue; якщо ви просто хочете чергу чи двояку чергу в якості структури даних, використовуйте collections.deque.

Нарешті, отримати доступ до маніпуляцій та керувати ними внутрішнім деком - Queue.Queueце гра з вогнем - ви насправді не хочете цим займатися.

Якщо все, що ви шукаєте, - безпечний для потоків спосіб передачі об'єктів між потоками , то обидва будуть працювати (як для FIFO, так і для LIFO). Для FIFO:

• Queue.put()і Queue.get()є безпечними для ниток
• deque.append()і deque.popleft()є безпечними для ниток

Примітка:

• Інші операції на, dequeможливо, не є безпечними для потоків, я не впевнений.
• dequeне блокується pop()або popleft()тому ви не можете базувати потоки споживчих ниток на блокуванні, поки не надійде новий товар.

Однак, схоже, що деке має значну перевагу в ефективності . Ось деякі результати орієнтиру за секунди, використовуючи CPython 2.7.3 для вставки та видалення 100k елементів

deque 0.0747888759791
Queue 1.60079066852

Ось базовий код:

import time
import Queue
import collections

q = collections.deque()
t0 = time.clock()
for i in xrange(100000):
    q.append(1)
for i in xrange(100000):
    q.popleft()
print 'deque', time.clock() - t0

q = Queue.Queue(200000)
t0 = time.clock()
for i in xrange(100000):
    q.put(1)
for i in xrange(100000):
    q.get()
print 'Queue', time.clock() - t0

Для інформації є квиток на Python, на який посилається безпека потоків deque ( https://bugs.python.org/issue15329 ). Заголовок "уточнити, які методи deque безпечні для потоків"

Підсумок тут: https://bugs.python.org/issue15329#msg199368

Операції append (), appendleft (), pop (), popleft () та len (d) є безпечними для потоків у CPython. У методах додавання є DECREF в кінці (для випадків, коли встановлено maxlen), але це відбувається після того, як були зроблені всі оновлення структури та відновлені інваріанти, тож добре розглядати ці операції як атомні.

У будь-якому випадку, якщо ви не впевнені на 100% і віддаєте перевагу надійності щодо продуктивності, просто поставте подібний Lock;)

Усі одноелементні методи dequeє безпечними для атомів та потоків. Усі інші методи також є безпечними для потоків. Такі речі , як len(dq), dq[4]дають моментальні правильні значення. Але подумайте, наприклад dq.extend(mylist): ви не отримуєте гарантії, що всі елементи в mylistфайлі подаються підряд, коли інші потоки також додають елементи з тієї ж сторони, - але це зазвичай не є вимогою в міжпотоковому спілкуванні та для заданого питання.

Тож a на deque20 разів швидше, ніж Queue(що використовує dequeпід кришкою), і, якщо вам не потрібен "комфортний" API синхронізації (блокування / таймаут), чітке maxsizeдотримання або "Перевизначення цих методів (_put, _get, .. ) реалізовувати поведінку підкласових класів інших організацій черги або коли ви самі подбаєте про такі речі, тоді голі deque- це хороша та ефективна угода для високошвидкісного міжпотокового спілкування.

Насправді, велике використання додаткового методу мютексу та додаткового методу ._get()тощо Queue.pyвикликане обмеженнями сумісності назад, минулим надмірним дизайном та відсутністю турботи щодо забезпечення ефективного вирішення цієї важливої ​​проблеми із швидким вузьким місцем у комунікації між потоками. Список використовувався в старих версіях Python, але навіть list.append () /. Pop (0) був & є атомним та поточним безпечним ...

Додавання notify_all()до кожного deque appendі popleftпризводить до набагато гірших результатів, dequeніж 20-кратне покращення, досягнуте за dequeповедінкою за замовчуванням :

deque + notify_all: 0.469802
Queue:              0.667279

@Jonathan трохи змінить його код, і я отримую орієнтир за допомогою cPython 3.6.2 і додаю умову в циклі deque, щоб імітувати поведінку в черзі.

import time
from queue import Queue
import threading
import collections

mutex = threading.Lock()
condition = threading.Condition(mutex)
q = collections.deque()
t0 = time.clock()
for i in range(100000):
    with condition:
        q.append(1)
        condition.notify_all()
for _ in range(100000):
    with condition:
        q.popleft()
        condition.notify_all()
print('deque', time.clock() - t0)

q = Queue(200000)
t0 = time.clock()
for _ in range(100000):
    q.put(1)
for _ in range(100000):
    q.get()
print('Queue', time.clock() - t0)

І, здається, продуктивність обмежена цією функцією condition.notify_all()

collection.deque - це альтернативна реалізація необмежених черг з операціями швидкого атомного додавання () та popleft (), які не потребують блокування. Черга документів

dequeє безпечним для ниток. "операції, які не потребують блокування" означає, що вам не доведеться робити блокування самостійно, це dequeтурбується про це.

Поглянувши на Queueджерелі, внутрішній Deque називається self.queueі використовує м'ютекс для аксессор і мутацій, так що Queue().queueце НЕ поточно- для використання.

Якщо ви шукаєте оператора "in", то дека або черга, можливо, не є найбільш підходящою структурою даних для вашої проблеми.

(здається, я не маю репутації коментувати ...) Ви повинні бути обережними, які методи деке ви використовуєте з різних ниток.

deque.get (), здається, безпечний для потоків, але я виявив, що це робить

for item in a_deque:
   process(item)

може не вдатися, якщо інший потік одночасно додає елементи. Я отримав RuntimeException, який скаржився на "deque mutiated під час ітерації".

Перевірте collectionmodule.c, щоб побачити, на які операції впливає це