Яке значення слів асинхронних та синхронних в інформатиці?

Якщо ви перейдете значення google, ви отримаєте наступне:

• Асинхронний: не існує або виникає одночасно .

• Синхронні: існуючі або виникають одночасно .

Але, схоже, вони використовуються для передачі протилежного значення в програмуванні або інформатиці:

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

Чи використовуються ці терміни для передачі протилежного значення в інформатиці чи я пропускаю суть?

Я хотів би дати вам відповідь, яка безпосередньо стосується тих визначень, які ви знайшли. Коли одне завдання T1 запускає друге завдання T2, це може статися таким чином:

Синхронні: існуючі або виникають одночасно.

Таким чином, T2 гарантовано запускається та виконується всередині часового відрізка T1 . T1 "чекає" закінчення T2 і може продовжувати обробку після цього. У цьому сенсі Т1 і Т2 відбуваються "в один і той же час" (не "паралельно", а в суміжному часовому інтервалі).

Асинхронний: не існує або виникає одночасно.

Отже час виконання T2 зараз не пов'язаний з T1. Це може бути виконано паралельно, це може статися через одну секунду, одну хвилину або кілька годин пізніше, а T2 все ще може працювати, коли T1 закінчився (тому для обробки результату T2 може знадобитися нове завдання T3). У цьому сенсі Т1 і Т2 не "виникають одночасно (інтервал)".

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

Я вважаю, що найкращий спосіб зрозуміти це:

• Синхронний: Ми знаємо, коли це станеться (це трапиться, коли закінчиться цей інший код).
• Асинхронний: Ми не знаємо, коли це станеться.

Примітка. Хоча ми можемо запланувати код, який потрібно виконати заданий годинний час, на практиці ми не знаємо, коли це відбудеться, тому що він може затягнутися - навіть ігноруючи возитися з системним годинником, - оскільки система зайнята чимось іншим. Крім того, навіть якщо ми мали гарантію, що це відбуватиметься точно в заданий годинний час, ми не впевнені, де саме було б виконання нашої програми на той час. Отже, ні, код, запланований на годинний час, не є синхронним.

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

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

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

До речі, незважаючи на те, що деякі речі є принципово асинхронними, ми можемо робити вигляд, що вони не є. Ми робимо це, маючи програмне забезпечення блокувати поточне виконання - і нічого іншого не роблячи - до його завершення. Тобто ми можемо взяти щось асинхронне і загорнути його в синхронний API.

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

Варто зазначити, що асинхронність не означає одночасність. У деяких випадках платформа може виконати асинхронне завдання лише після того, як поточне завдання виконане. Це було б послідовно (хоча порядок виконання асинхронного завдання не обов'язково гарантується), не був би одночасним (немає перекриттів у періоди виконання), проте був би асинхронним.

О, до речі, на деяких платформах система може вирішити вбудувати асинхронну задачу і, таким чином, виконати її прямо як синхронну операцію (якщо припустити, що це не під силу кожному завдання).

Знову ж таки, асинхронність просто означає, що ви не знаєте, коли це станеться.

Можливо, вас також зацікавить різниця між "паралельним" та "паралельним" виконанням? .

Асинхронний: не існує або виникає одночасно.

Синхронні: існуючі або виникають одночасно.

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

Це справді заплутано!

Розглянемо натомість значення синхронізованого та несинхронізованого . Дві речі синхронізуються, якщо час однієї залежить від іншої, і несинхронізовані, якщо їх час не пов'язаний.

У вашому прикладі асинхронного робочого процесу у нас відбувається дві речі: виконання сценарію та аналіз HTML. Ці дві речі несинхронізовані ; терміни виконання операції та терміни операції розбору не залежать один від одного. Якби ми зробили робочий процес синхронним , то операції стали б синхронізованими . Скажімо, виконання не починається до тих пір, поки синтаксичний аналіз точно не закінчиться.

Але важливо усвідомити, що насправді тут є три можливості:

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

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

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

• awaitОператор в мовах програмування, як C # є операцією впорядкування на асинхронних робочих процесах. Очікування - це асинхронне очікування ; це точка , в якій ми висловлюємо ставлення порядку між двома частинами асинхронного процесу, і сказати , що це «відбувається до» відносин між кодом перед очікування і кодом після ОЧІКУВАННЯ. Ось як ми реалізуємо третій варіант .

Якщо це все занадто абстрактно, придумайте кілька реальних прикладів. Коли ви надсилаєте лист - операція, пов'язана з високим запізненням введення / виводу, - ви все ще можете робити інтенсивну роботу з процесором - математичне домашнє завдання, скажімо, - поки ви чекаєте отримання відповіді на ваш лист. Операції виконання домашнього завдання з математики та читання вашої пошти не синхронізовані.

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

Я інженер-електрик, і ми мали справу з синхронними проти асинхронними в логічних схемах (логічні ворота).

Скажімо, у вас є ворота AND (або будь-які ворота), які мають два входи та вихід.

Якщо він асинхронний, він буде оновлювати свій вихідний момент, коли будь-який з входів зміниться таким чином, що результат зміниться. Ось як працював ваш приклад - програма, яку ви згадали.

Однак якщо до цього затвору також прикріплений годинник (наприклад, квадратна хвиля періоду на 1 секунду), де він оновлюється в такт кожної секунди, оскільки квадратна хвиля йде від низької до високої, вона є синхронною. Він пов'язаний з частотою тактової частоти. Так це синхронно. Ви можете підключити цей годинник до багатьох мікросхем, і вони будуть працювати в ритмі один з одним - синхронізованими. Якщо ваша програма лише перевіряла, чи читається вона запуск кожної секунди, вона також буде синхронізована.

Уявіть, що навколо Землі обходять два супутники.

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

Супутник B у наведеному вище прикладі знаходиться на геосинхронній орбіті, як визначено

періоду обертання, синхронного періоду обертання Землі.

Не можна стверджувати, що супутник A є геосинхронним просто тому, що він "існує або відбувається [s] одночасно", як і планета. Насправді, супутник B сам по собі теж не є актуальним - важливим є період обертання, який синхронізується з періодом обертання до періоду Землі. Йдеться не про одночасне існування об'єктів; йдеться про взаємозв'язок між об’єктами. Затримайте цю думку.

Припустимо, я кажу вам, що два потоки в системі працюють одночасно. Нитка A (TA) - це отримання даних для Process A, а Thread B (TB) - це отримання даних для Process B. Я запитую вас: "TA and TB asynchronous?". Ваша відповідь буде: "Як я можу знати? Я повинен бачити код, який викликав їх у відповідних процесах". На що я б приступив до своєї спроби бути хитрою: "Але я кажу вам, що ТА та ТБ безумовно працюють одночасно".

А ви, будучи досить розумною особою, відповіли б: "Знову ж - вони можуть працювати одночасно, але я не маю поняття, якщо вони працюють асинхронно щодо відповідних процесів, які викликали їх. ТА і ТБ, що працюють асинхронно один до одного, дійсно робить немає сенсу, оскільки вони не були породженими одним процесом ".

Тож до цього часу нам слід набути певної інтуїції, що існування відносин - це те, що тут є актуальним, а не лише існування цих двох ниток. Коли метод виконується асинхронно, те, що ми говоримо, полягає в тому, що виконання цього методу " НЕ потрібно існувати або виникати одночасно", ніж виконання методу, який викликав його. Візьмемо такий приклад:

func Invoker() {
    DoThis();
    DoThatAsync();

    var foo = CheckThis();
    ... do some work ...
    CheckThat(foo);

    await DoThatAsync();

    CheckThat();
}

З нашого обговорення супутників раніше, "йдеться не про одночасне існування об'єктів; це про взаємозв'язок між об'єктами". Йдеться не про існування методу викликання та методу, який викликається; йдеться про існування зв’язку між виконанням виклику та виконанням викликаного. Якщо ми подивилися на наші системні потоки і виявили, що DoThatAsync()викликано, але не виконується, можливо, він чекає на планувальнику чи іншому вході / виводу, це не обов'язково означає, що метод виклику Invoker()не виконується - там може працювати робити. Звичайно, це може бути в точці awaitING DoThatAsync(), але не гарантується. Це не стосується інших функцій після їх виклику - якщо вони зупиняються,Invoker()зупинки - незалежно від того. Це гарантовано. Виконання між Invoker()синхронним методом та викликаним ним "існує або відбувається одночасно".

Конкретні приклади

Я хотів би додати кілька реальних прикладів та підключити їх до світу інженерії програмного забезпечення. По-перше, подумайте про те, що, сподіваюся, відповідає вашому інтуїтивному визначенню "синхронного": спалахування світлячків за певних обставин. По- друге, розглянемо релейний олімпійський 4х100 жінок гонки . По-третє, вважайте, що стара трупа з військових фільмів: "Чоловіки, синхронізуйте годинник!"

Тепер давайте подумаємо, що відбувається. Для початку почнемо, спостерігаючи, що всі ці речі - це процеси або сутності, розширені в часі . Немає сенсу говорити, що чаша "синхронна", а рок - "асинхронний". По-друге, на танго потрібно два . Ви не можете сказати, що "бігун синхронізується". Синхронізувати з чим? Нарешті, для того, щоб два процеси одночасно могли робити щось, якщо вони вже не мають точно однакової частоти та фази, один або обидва повинні почекати .

Аналіз

Коли в словниковому визначенні сказано, що два об'єкти синхронізуються "виникають або існують одночасно", це дуже добре узгоджується з поняттям світла від світлячків. На жаль, сказати, що світло "синхронізоване" - це неохайний спосіб сказати, що процеси освітлення світлячків синхронізовані.

То як же куля світлячків, які, мабуть, не мають Apple SmartWatch та NTP, щоб керувати ними, встигнути одночасно спалахнути задніми кінцями? Ну, це досить просто, якщо вони мають засоби для встановлення послідовного темпу і можуть внести невеликі корективи в нього. Вони просто спалахують, і якщо більше людей спалахує відразу після них, вони сповільнюються (збільшують затримку), тоді як якщо більше спалахує прямо перед ними, вони прискорюються (зменшують затримку). Таким чином, вони можуть використовувати простий процес зворотного зв'язку, щоб досягти фактично однакового темпу та фази. Тут важливим є зауваження, що вони досягають синхронності, чекаючи, коли потрібний момент спалахне .

Гонка 4x100 цікава тим, що ви бачите обидві форми хронометражу процесу: бігуни в команді синхронізовані, а бігуни в різних командах "асинхронізовані". Другий бігун в естафеті повинен чекати, поки перший бігун потрапить у зону передачі . Передача - це синхронна подія між цими двома бігунами. Однак бігунів на різних смугах все одно, що відбувається на іншій смузі , і, звичайно, не сповільнюються і синхронізуються. Кожна смуга бігунів асинхронна відносно один одного. Знову ми бачимо, що синхронізація тягне за собою очікування, а асинхронність - ні.

Нарешті, солдати в компанії (взвод, пожежної команди і т.д.) повинні синхронізувати свій годинник , щоб вони могли атакувати противника одночасно . Можливо, деякі солдати приходять на свої позиції перед іншими, або мають можливість швидше обстрілювати ворога. Але одночасний напад, як правило, є більш ефективним, ніж випадковий напад через стилю здивування. Отже, щоб досягти синхронності, багатьом солдатам необхідно чекати призначеного часу для дії.

Визначення функції

Чому саме цей акцент на очікуванні? Ну, це тому, що очікування - визначальна особливість, яка відрізняє синхронність від асинхронних процесів. Якщо у вас є два процеси, про які ви нічого не знаєте, вам слід за замовчуванням припустити, що вони асинхронні. Наприклад, доставка пакетів та швидка допомога, швидше за все, не синхронізовані. Для того, щоб продемонструвати, що два процеси насправді синхронізовані, вам потрібно знайти дуже особливий момент часу: точку синхронізації .

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

Межі

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

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

Підключення до програмного забезпечення

Тепер давайте подумаємо про дуже фундаментальне завдання програмного забезпечення: читання з файлу. Як ви, напевно, знаєте, масове зберігання зазвичай в тисячі-мільйони разів повільніше, ніж кеш або основна пам'ять. З цієї причини операційні системи та бібліотеки мов програмування зазвичай пропонують як синхронні, так і асинхронні операції вводу / виводу. Тепер, навіть якщо у вашій програмі є лише одна нитка, для цілей цієї дискусії слід вважати, що ОС є "окремим процесом".

Синхронізація

Коли ви робите "синхронне зчитування вводу / виводу", ваш потік повинен зачекати, поки дані стануть доступними, і в цей момент він продовжується. Це дуже схоже на естафету, який передає естафету наступному бігуну, але уявіть замість цього естафету з двома бігунами, які проходять всю дорогу навколо траси, а другий бігун також відступає назад до першого.

У цьому випадку ваш програмний потік та процес введення / виводу ОС не "відбуваються (діють) одночасно", і тому дивно говорити, що ці процеси "синхронізовані". Але це неправильний погляд на це! Це як сказати: "Бігуни в естафетній команді не працюють одночасно, тому вони не синхронізуються". Насправді обидва твердження помилкові! Бігуни в естафетній команді роблять і повинні бігати одночасно, але тільки в дуже конкретний момент: передача естафети. Насправді, саме цей особливий момент під час гонки переконує нас, що естафетні команди синхронізуються для початку! Якщо ми розглядаємо запит і відповідь вводу / виводу як "естафету",

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

Різноманітність процесу

З цієї причини ми можемо винайти кілька термінів, які допоможуть нам побачити, що триває три речі: "однорідна синхронія", "неоднорідна синхронія" та "послідовна синхронія". Тож коли актори виконують одне і те ж завдання одночасно (FEA, світлячки), вони «однорідні». Коли вони виконують різні завдання одночасно (солдати, які бігають проти повзання та плавання до місця призначення, фізика проти звуку проти AI-потоків у грі), вони "неоднорідні". Коли вони виконують завдання по черзі, вони є "послідовними" (естафети, блокуючи введення-виведення). Вони можуть виглядати дуже по-різному, але вони мають одне суттєве властивість: всі типи акторів виконують певні очікування, щоб усі прийшли в точку синхронізації одночасно. між точками синхронізації, або "виконання тієї ж дії" не має значення властивості синхронізації.

Трубопроводи візуалізації в графічному процесорі синхронізовані, оскільки всі вони повинні закінчувати кадр разом і починати новий кадр разом. Вони однорідні, тому що роблять однакові роботи, і всі вони разом активні. Але основна ігровий цикл сервера та блокуючі потоки вводу / виводу, які обробляють віддалений вхід, неоднорідні, оскільки вони виконують дуже різні види роботи, а деякі потоки вводу / виводу взагалі нічого не роблять, тому що не всі використовуються з'єднання. Незважаючи на це, вони синхронізовані, тому що вони повинні мати загальний стан атоми (гравець не повинен бачити часткового оновлення світу ігор, а також сервер не повинен бачити лише фрагмент введення гравця).

Асинхронізація

Тепер розглянемо "читання асинхронічного вводу / виводу". Коли ваша програма надсилає запит в ОС, щоб прочитати трохи даних із сховища, виклик негайно повертається . Давайте ігноруємо зворотні дзвінки та зосередимось на опитуванні. Загалом, момент, коли дані доступні для вашої програми, не відповідає жодному спеціальному моменту часу, що стосується потоку вашої програми. Якщо ваша програма явно не чекає даних, то потік навіть не буде точно знати, коли настає цей момент. Він виявить лише, що дані чекають наступного разу, коли вони перевірять.

Немає спеціального часу зустрічі, коли ОС і програмний потік погоджуються передавати дані. Вони як два кораблі, що проходять у ніч. Асинхронність характеризується цією відсутністю очікування. Звичайно, програмний потік часто закінчує очікування операції вводу / виводу, але цього не потрібно. Він може із задоволенням продовжувати робити інші обчислення, поки відбувається виведення вводу / виводу, і перевіряти лише пізніше, коли у нього є запасний момент. Звичайно, щойно ОС працює за отриманням даних, вона теж не сидить навколо очікування. Він просто розміщує дані десь зручно і продовжує свою справу. У цьому випадку це все одно, що програма передає естафету ОС, а ОС з'являється пізніше, опускає естафету на землю разом із даними та виходить зі сліду. Програма може або не може чекати, щоб отримати роздачу.

Паралелізм

Коли ми позначаємо функцію як "асинхронізацію" в програмному забезпеченні, це часто означає, що ми хочемо паралелізму . Але пам’ятайте, що паралелізм не передбачає синхронності . Світлячки - хороший приклад, тому що вони теж виявляють як синхронну, так і асинхронну поведінку. У той час як більшість мух блимали в унісон, багато хто, очевидно, не відповідали решті групи і блиснули більше випадково. Мухи, можливо, діяли одночасно , але вони були не всі синхронізовані .

Тепер, коли ми позначаємо якийсь код як "асинхронний", він виглядає смішно, оскільки це означає, що решта коду, не так позначеного, є "синхронізація". Що це навіть означає? Хіба ми не наполягали на тому, що для сингонізації потрібно два для танго? Але що робити, якщо ми говоримо про виконання коду в одному потоці? У цьому випадку нам потрібно зробити крок назад і продумати програму як послідовність станів і переходів між цими станами. Заява в програмі викликає перехід стану. Ми можемо вважати це як "мікропроцес", який починається і припиняється з твердженням. Точки послідовності, визначені мовою, насправді є точками синхронізації цих "мікропроцесів". Таким чином, ми можемо переглянути однопотокові,

Цілісність мови програмування гарантує, що оновлення стану не перешкоджають операторам, а точки послідовності визначають межі, через які компілятору не дозволяється робити оптимізації, що спостерігаються. Наприклад, порядок оцінки виразів у висловлюванні може бути невизначеним або недоозначеним, що дає компілятору свободу оптимізувати висловлювання різними способами. Але до початку наступного твердження програма повинна бути в чітко визначеному стані, якщо ПЛ сам по собі звучить.

На сьогоднішній день має бути зрозуміло, що ми маємо на увазі під «асинхронією». Це означає саме те, що мається на увазі контракт синхронії в блоці коду вилучається для блоку асинхронізації. Дозволяється оновлювати стан програми самостійно, без гарантій безпеки, як правило, мається на увазі послідовна (послідовна, синхронна) модель обчислення. Звичайно, це означає, що нам потрібно бути особливо обережними, щоб ми не руйнували стан програми з непослідовністю. Зазвичай це означає, що ми вводимо обмежену, явну синхронність для координації з блоком асинхронізації. Зауважте, що це означає, що блок асинхронізації може бути як асинхронним, так і синхронним у різний час! Але нагадуючи, що синхронізація лише вказує на існування точки синхронізації, у нас не повинно виникнути проблем з прийняттям цього поняття.

Один із способів подумати над цим - це інструкції SIMD , наприклад, AVX . Ось кілька прикладів того, як вони використовуються.

Синхронні інструкції SIMD дозволяють робити декілька обчислень точно в один і той же час , в одній і тій же потоці, використовуючи єдину інструкцію з кількох даних.

Хоча асинхронна багатопотокова редакція дозволяє робити кілька обчислень у "ймовірно" "дещо" "подібні" часи.

Поєднайте це з такими визначеннями:

синхронний прикметник syn · chro · nous | \ ˈSiŋ-krə-nəs, ˈsin-

1: відбувається, існує або виникає точно в один і той же час [акцент мій]

асинхронний прикметник asyn · chro · nous | \ (ˌ) ā-ˈsiŋ-krə-nəs, -ˈsin- \

1: [...]: не синхронно

Аналогія, яка змусила мене зрозуміти різницю між синхронізацією проти Async проти багатопотокової, - це кухар на кухні.

Уявіть, що ви робите макарони. Ви маєте три кроки:

1. Відварити і злити макарони
2. Приготуйте соус
3. Поєднайте макарони та соус

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

Асинхронний метод. У цьому сценарії все ще залишається лише один кухар (нитка), але поки макарони киплять, ти йдеш і робиш свій соус. Коли макаронні вироби закип'ятяться, ви called-backробите соус для його зливу, і тоді ви called-backзнову закінчите соус. Зараз це ефективніше, адже ви заощадили час, і ваші макарони не повинні були чекати соусу так довго.

Багатопотоковий метод. А тепер уявіть, що ви найняли нового кухаря. Тепер у вас є два кулінари (нитки). Поки один кухар робить макарони, другий кухар готує соус. Чи потрібно в цьому сценарії? Ні, адже виготовлення пасти досить просте, щоб бути ефективним за допомогою асинхронного методу. А управління кількома кухарями - це додаткові витрати. Але якщо ви робили складніше блюдо або більше страв одночасно, корисні кілька кухарів.

Хороше запитання та терміни, які часто використовуються по-різному, що призводять до плутанини.

Моя відповідь полягає в тому, що ці терміни відносні - і те, що вони відносно, - це основна програма, яка виконується (або іноді для потоку).

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

(IMHO, звичайно), коли повідомлення з’являється на дроті, не існує такого поняття, як синхронізація проти асинхронізації. У обміні повідомленнями є відправник і приймач, кожен з них може мати синхронізацію чи асинхронізацію незалежно від інших - але коли повідомлення з’являється на дроті, це просто повідомлення, більше не синхронізація чи асинхронізація. Ми можемо класифікувати повідомлення як запит чи відповідь або повідомлення в одну сторону, але це ортогональне для синхронізації та асинхронізації (які посилаються на те, чи блокується реалізація в очікуванні чи може бути перервана якимось чином).

"синхронний" означає, що дві події відбуваються одночасно - але які події?

Коли ми говоримо "синхронне виконання", ми маємо на увазі, що абонент і виклик виконуються (тобто в стеці) одночасно. Це, мабуть, той сенс, який ви шукаєте.

Коли ми говоримо "синхронні логічні ворота", ми маємо на увазі, що логічний затвор синхронізований з тактовою частотою процесора.

Коли ми говоримо "синхронна модель" в розрізі розподілених систем, ми маємо на увазі, що всі вузли виконують свої програми на етапі блокування, а повідомлення, надіслані на етапі n, гарантовано надходять на початок кроку n + 1.

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

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

Я думаю, що ключ вашої плутанини можна підсумувати:

Атрибут async означає, що сценарій буде виконаний, як тільки він буде завантажений, навіть якщо html ще розбирається

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

У програмуванні синхронні засоби:

Всі дані, які вас цікавлять, вже існують у пам'яті під час виконання вашої логіки

Хоча асинхронний означає:

Деякі дані, які вас цікавлять, ще не існують і існують лише в якийсь момент у майбутньому

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

Як завантажуються сценарії, як правило, призупинення розбору html призупиняється, потім завантажується сценарій, після завершення завантаження сценарію виконується і далі розбір html продовжується. Синтаксичний аналіз і виконання сценарію відбувається в "той самий" час (один і той же час означає разом, а не одночасно).

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

Отже, підсумовуючи:

• Синхронні сценарії розбираються разом з html.

• Асинхронні сценарії в майбутньому аналізуються окремо.

Отже, визначення asyncвластивості полягає не в тому, що сценарій виконується, як тільки він завантажується - це справедливо як для синхронних, так і для асинхронних сценаріїв. Визначення async - це аналіз HTML не чекає завантаження сценарію .