Яка різниця між потоком і чергою?

Яка різниця між потоком і чергою? Вони обидва мають концепцію впорядкованого набору елементів, але, як правило, мають різні реалізації та різну лексику "вставити" / "витягнути" (потоки) порівняно з "enqueue" / "dequeue" (черга). Ці взаємозамінні? Вони пропонують різні концепції чи зразки? Якщо так, то які відмінності?

Потік в дійсності не є структурою даних як такої (концептуально), але являє собою послідовність кодованих в цифровому вигляді когерентних сигналів (пакетів даних або пакетів даних) , які використовуються для передачі або прийому інформації ». Таким чином , в основному послідовність даних.

Черга є простий механізм FIFO дозволяє додавати елементи в задній частині черзі або взяти з фронту.

У потоків завжди є джерело, наприклад файл, мережеве розташування тощо. Черга по суті не містить жодних даних.

Отже, вони принципово різняться, і, як зазначав Мейсон, вони використовуються по-різному.

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

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

На мій досвід, потік - це послідовність байтів, які виробляються / споживаються зі швидкістю, часто визначається даними всередині потоку. Наприклад, потік даних MPEG матиме заголовки кадрів, які описують, що робить наступна послідовність байтів і скільки потрібно споживати. Бінарна серіалізація документа була б подібною. Це не завжди самоописується: запис до STDOUT може здійснюватися в потоковому режимі, але це можуть бути людські читані / нерозбірливі дані.

І навпаки, черга - це звичайно відомий тип об'єктів (або підтримуючих інтерфейс) об'єктів, які споживаються в повному обсязі. Прикладом може бути черга завдань із бази даних, які обробляються рядом працівників бази даних.

Різниця між потоком і чергою - це спосіб управління швидкістю передачі даних:

• у черзі відправник адаптується до швидкості зчитування. Відправник вирішує, що робити, якщо черга заповнена: дочекайтеся наявності черги або викиньте дані.

• у потоці зчитувач адаптується до швидкості відправника. Читач вирішує, що робити, якщо нові дані надходять до того, як будуть використані старі.

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

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

• Черги очікування людей в черзі і обслуговуються по одному. Більше людей приєднується до черги в хвіст. Усі чекають, коли триває обслуговування, і очікується, що час обслуговування буде різним. Ви можете говорити про те, скільки людей обслуговують загалом.
• Потік людей, наприклад , виходячи з будівлі через двері, не служив один за іншим, вони просто проходять точку виходу на більш-менш постійною швидкістю. Затримки не очікуються і не переносяться добре. Можна говорити про норму людей: один за секунду.

Такий намір цих умов. Вони - метафори. (як і все інше) (Shhh! ти зіпсуєш історію!)

Черга - це концепція вищого рівня, ніж потік. Основними елементами черги є повідомлення / об’єкт, який є цілісною (зазвичай набирається) структурою даних, яку споживач може інтерпретувати самостійно. З іншого боку, в основі потоку є (зазвичай фіксованого розміру) біти / байти / символи, які самі по собі, як правило, безглузді для програми. Послідовність цих символів може складати "повідомлення", але API потоку залишає його програмі, щоб розділити послідовність символів на чутливі фрагменти.

API Stream зазвичай також дозволяє частково читати і записувати, якщо буфери потоків заповнені, а інша сторона не читає / записує; програми, які обробляють черги, зазвичай очікують, що чергу буде їх обробляти внутрішньо.

Черга може бути реалізована над потоком, це робиться шляхом запровадження обрамлення повідомлень. Наприклад, TCP надає потоковий інтерфейс, HTTP побудований поверх TCP і додає обрамлення повідомлень за допомогою кодування передачі вмісту / довжини вмісту. Користувачі API HTTP Connection абстрагуються від розбиття потоку HTTP-з'єднання на HTTP-запити.

З іншого боку, зазвичай, має менший сенс впроваджувати API потоку поверх черги, оскільки обробка кадрів з повідомленнями додає зайві накладні витрати.

У функціональних мовах програмування (наприклад, Scala), а може бути й інших мовах, потоки справді більше схожі на функціональні списки, і вони стоять у черзі. Хочу зазначити, проте черги можуть бути реалізовані за допомогою пари списків . У Скалі та, ймовірно, в інших місцях, Потік - це лише лінивий список - точніше, хвіст списку - це lazy val.

Функціональні потоки можуть поділяти певну схожість з чергами, на відміну від списків, завдяки чому ви можете використовувати їх таким чином, щоб не зберігати посилання на голову потоку - але ви повинні бути обережними: https: // stackoverflow.com/a/5159356/3096687 . Це дещо аналогічно виклику вимкнення черги (хоча у випадку потоку ви робите це неявно: http://daily-scala.blogspot.com/2010/01/streams-2-stream-construction.html ).

Потік - це концепція / рамка для створення та споживання нескінченної послідовності даних послідовно, паралельно чи масово. Que - структура даних, за допомогою якої можна реалізувати потік. так само, як список або послідовність, через які можна реалізувати потік.