Google удари ноктите на главата още с първия ред в „„ListenableFutures Explained““ — Паралелността е трудна. С това казано, единственото възпиращо средство, което някога съм познавал, е скуката, която е малко вероятно да възникне, докато решавам труден проблем като този. И така, ето ме!

Ще започна с причините, поради които приемам тази концепция:

  1. В момента разработвам мащабируем инструмент за автоматизиране на мобилни тестове, използвайки Appium. Всяка Appium сесия изисква собствен Appium сървър, на който да работи. Appium наистина предлага вграден начин за стартиране на услугата, но от всички скорошни акаунти, които успях да намеря, това в момента не работи (нещо, което забелязах лично, но бях твърде неопитен, за да хвърля окончателно вината върху трета страна). И така, трябва да използвам паралелността, за да оптимизирам скоростта на автоматизиране на теста за възможно най-много сесии.
  2. Аз съм упорит и не обичам да не разбирам нещо, така че тази причина не е нищо друго освен чист инат
  3. След продължително четене онлайн на огромен брой многонишкови статии, скоро бях очарован от основната механика на нишките и как те работят на различните операционни системи. До този момент бях наясно с концепциите за нишки и компютърния хардуер на отделни дължини на вълната и всъщност не бях мислил много за това как те взаимодействат помежду си, тъй като неправилно предположих, че под капака има цял куп магии за ОС - просто си помислих, че е просто извън обхвата на това, което трябваше да знам.

И така, необходимостта, упоритостта и огромният развиващ се интерес са всички причини зад които пиша това. Тази статия НЕ е предназначена като ръководство, а по-скоро като част от човешкия интерес, която служи или като сърдечен смях на моите глупави грешки, или за някакво полезно прозрение, получено от моето изследване. Въпреки че, разбира се, всяко прозрение ще бъде по-скоро функция за „късна игра“, тъй като все още съм нов в това, така че, ако се позовавате на тази статия като на някакъв вид ръководство, с божествена скорост, смела душа. Подгответе се за главоболие

Многорезбови гайки и болтове

Прекарах много време, за да науча колкото се може повече за нишките и какво точно представляват те за операционната система. Поради цялото време, което прекарах, чувствам, че мога да дам някаква смислена представа по въпроса. Класът вече е в сесия.

Въпреки това, тъй като часовете се провеждат в колежа, а колежът е скъп, ето моето разбиране на Google-Fu:

  • Нишките и процесите не са едно и също нещо —всеки процес се състои от нишки. В рамките на всеки процес във всеки един момент се изпълнява една нишка. (Това не е съвсем правилно - вижте коментара ми по-долу)
  • Процесите имат самостоятелни групи от нишки — това са всички нишки, които даден процес може да използва. Тези нишки не са достъпни за външни процеси.
  • Паралелността е възможна както на едноядрени CPU системи, така и на многоядрени CPU системи. При едноядрени, едновременните процеси споделят времето за обработка чрез „os-splitting“, което разделя времето, прекарано на всяка активна нишка, въз основа на броя на активните нишки. Това означава, че колкото повече процеси се изпълняват, толкова повече време ще отнеме завършването на всеки процес. При многоядрени системи разделянето на OS все още се случва, но е възможно да се ограничи максималния брой изпълнявани процеси до максималния брой налични ядра (това може да се постигне чрез създаване на нова „работа -пул за кражби“). Ако ограничите броя на активните процеси до броя на наличните ядра, тогава вие осигурявате максималното ниво на паралелност при възможно най-бързите изчислителни времена за системата (всяко ядро ​​обработва нишки независимо).

Осъзнавам, че някои от бележките ми може да не са напълно правилни (моля, коментирайте, ако случаят е такъв — искам да науча, по дяволите!), но не планирам да се връщам и да коригирам тази статия. Искам да следя напредъка си като разработчик от мястото, където започнах, и тази статия е един от начините да правя точно това.

Какво ще кажете за хардуерното ниво на многопоточността?

Добър въпрос. Да видим дали съм разбрал правилно — има два основни типа операционни системи:

  1. Кооперативна многозадачна система
  2. Превантивна многозадачна система

Кооперативната многозадачна система е такава, при която всяка задача трябва доброволно да отстъпи контрола на други задачи. Това е проблематично, тъй като всяка задача има потенциала да блокира изпълнението на следващи задачи, докато текущата не бъде завършена. Лично аз не вярвам, че има много системи, които работят по този начин, тъй като изглежда доста ограничен - повечето съвременни приложения изискват използването на едновременност, което просто не е възможно в кооперативните многозадачни системи.

Превантивните многозадачни системи са по-познатите системи (Windows и UNIX, например). В тези видове системи на задачите се дават „резени“ от процесора(ите). Основната разлика е, че в превантивните системи задачите са принудени да отстъпят контрола на други задачи веднага след като тяхното разпределение бъде изразходвано.

Как това е свързано с Happium?

Ето моя план:

  • Отделни пулове на сървърни и сесийни нишки
  • Блокирайте изпълнението на сесия при условие, че целевият сървър все още не слуша
  • Извеждане на нишката на сървъра до местоположение, където мога да наблюдавам за състояние на „слушане“.
  • Създайте „клас за групиране, който ще създаде максималния брой едновременни сървъри и сесии на appium

Всичко това са концептуални неща на много „високо ниво“, но както е в момента, вече имам тази система, работеща на основно ниво. Там, където съм заседнал, се опитвам да разбера най-добрия начин за наблюдение на изхода на сървъра. Предполагам, че ще се върна и ще актуализирам тази статия (нарушавайки правилото си, знам), за да кажа как в крайна сметка направих това. Дотогава отивам да си създавам още главоболия!