Vitalized thread что это
Обзор моделей работы с потоками
Обзор моделей работы с потоками
Начало (С и native threads)
Первая модель, которую мы рассмотрим — это стандартные потоки ОС (threads). Их поддерживает каждая современная ОС, несмотря на разницу в API. В принципе, поток — это процесс выполнения инструкций, который работает на выделенном процессоре, выполнение которого контролирует планировщик (scheduler) ОС, и который может быть заблокирован. Потоки создаются внутри процесса и пользуются общими ресурсами. Это означает, что, например, память и декскрипторы файлов, являются общими для всех потоков процесса. Подобный подход и принято называть native threads.
Linux позволяет использовать данные потоки с помощью библиотеки pthread. BSDs тоже поддерживают pthreads. Потоки Windows работают немного иначе, но базовый принцип тот же.
Java and Green Threads
Когда появилась Java, она принесла с собой другой тип многопоточности, который называется green threads. Green threads — это, по сути, имитация потоков. Виртуальная машина Java берёт на себя заботу о переключении между разными green threads, а сама машина работает как один поток ОС. Это даёт несколько преимуществ. Потоки ОС относительно дороги в большинстве POSIX-систем. Кроме того, переключение между native threads гораздо медленнее, чем между green threads.
Это всё означает, что в некоторых ситуациях green threads гораздо выгоднее, чем native threads. Система может поддерживать гораздо большее количество green threads, чем потоков OС. Например, гораздо практичнее запускать новый green thread для нового HTTP-соединения к веб-серверу, вместо создания нового native thread.
Однако есть и недостатки. Самый большой заключается в том, что вы не можете исполнять два потока одновременно. Поскольку существует только один native thread, только он и вызывается планировщиком ОС. Даже если у вас несколько процессоров и несколько green threads, только один процессор может вызывать green thread. И всё потому, что с точки зрения планировщика заданий ОС всё это выглядит одним потоком.
Начиная с версии 1.2 Java поддерживает native threads, и с тех пор они используются по умолчанию.
Python
Python — это один из моих любимейших скриптовых языков и он был одним из первых предложивших работу с потоками. Python включает в себя модуль, позволяющий манипулировать native threads, поэтому он может пользоваться всеми благами настоящей многопоточности. Но есть и одна проблема.
Python использует глобальную блокировку интерпретатора (Global Interpreter Lock, GIL). Эта блокировка необходима для того, чтобы потоки не могли испортить глобальное состояние интерпретатора. Поэтому две инструкции Python не могут выполняться одновременно. GIL снимается примерно каждые 100 инструкций и в этот момент другой поток может перехватить блокировку и продолжить своё выполнение.
Сперва это может показаться серьёзным недостатком, однако на практике проблема не столь велика. Любой заблокированный поток как правило освобождает GIL. Расширения С также освобождают её когда не взаимодействуют с Python/C API, поэтому интенсивные вычисления можно перенести в C и избежать блокировки выполняющихся потоков Python. Единственная ситуация, когда GIL действительно представляет проблему — это ситуация когда поток Python пытается выполняться на многоядерной машине.
Stackless Python — это версия Python, которая добавляет “tasklets” (фактически green threads). По их мотивам был создан модуль greenlet, который совместим со де-факто стандартом: cPython.
Модель потоков Ruby постоянно меняется. Изначально Ruby поддерживал лишь собственную версию green threads. Это хорошо работает во многих сценариях, но не даёт пользоваться возможностями многопроцессорности.
JRuby перевёл потоки Ruby в стандартные потоки Java, которые, как мы выяснили выше, являются native threads. И это создало проблемы. Потокам Ruby нет необходимости взаимно синхронизоваться. Каждому потоку гарантируется, что никакой другой поток не получит доступа к используемому общему ресурсу. Подобное поведение было сломано в JRuby, так как native threads переключаются принудительно (preemptive) и поэтому любой поток может обратиться к общему ресурсу в произвольное время.
Из-за подобной несостыковки и желания получить native threads разработчиками C Ruby было решено, что Ruby будет переходить на них в версии 2.0. В состав Ruby 1.9 был включён новый интерпретатор, который добавил поддержку fibers, которое, насколько я знаю, являются более эффективной версией green threads.
Короче, модель потоков Ruby — это плохо документированная каша.
Perl предлагает интересную модель, которую Mozilla позаимстовала для SpiderMonkey, если я не ошибаюсь. Вместо использования глобальной блокировки интерпретатора как в Python, Perl сделал глобальное состояние локальным и фактически запускает новый интерпретатор для каждого нового потока. Это позволяет использовать настоящие native threads. Не обошлось и без пары загвоздок.
Во-первых, вы должны явно указывать переменные доступными для других потоков. Вот что происходит, когда всё становится локальным для потока. Приходится синхронизировать значения для межпоточного взаимодействия.
Во-вторых, создание нового потока стало очень дорогой операцией. Интерпретатор — большая штука и многократное копирование его съедает много ресурсов.
Erlang, JavaScript, C# and so on
Существует множество других моделей, которым время от времени находят применение. Например Erlang, использует архитектуру «ничего-общего» (shared nothing), которая стимулирует использование лёгких пользовательских процессов вместо потоков. Подобная архитектура просто великолепна для параллельного программирования, так как она устраняет всю головную боль насчёт синхронизации, а процессы настолько легки, что вы можете создать любое их количество.
JavaScript обычно не воспринимается как язык, который поддерживает работу с потоками, но она необходима и там. Модель работы с потоками в JavaScript очень похожа на ту, что используется в Perl.
C# использует native threads.
От себя: досаду на некоторую поверхностность статьи (которую я и сам осознаю) адресуйте автору. Я всего-навсего перевёл в меру своих скромных возможностей. 😉 Буду рад уточнениям и дополнениям в комментариях.
От себя 2: по мотивам комментариев таки подправил пару фраз. Прости, автор! 🙂
Война протоколов Internet of Things: Thread и прочие
И это при том, что уже существует несколько неплохих в общем-то стандартов автоматизации, таких как ZigBee, Insteon, Z-Wave и др.
Ситуация, которую мы наблюдаем сейчас, несколько напоминает конкуренцию между VHS и Betamax в восьмидесятых или стандартов записи дисков Blue Ray и HD-DVD в двухтысячных, только в значительно усложненной форме.
Сегодня существует множество устройств для «умного дома», которые не могут «общаться» друг с другом, пока наконец не будут разработаны единые правила и протоколы такого общения, пока кто-то не победит на этой войне или пока все не договорятся закончить ее, объединив свои усилия. А пока мы можем наблюдать перепалку между соперничающими группами, утверждающими, что именно они на правильном пути. И если это будет происходить, как на прошлых «войнах», мы будем наблюдать как компании-тяжеловесы будут присоединяться к тому или иному альянсу, а также читать множеств заявлений о важности таких перемещений. В итоге какая-то группа получит превосходство и все эти альянсы начнут сливаться, оставив нам что-то одно. И тогда, возможно, наступит время для настоящего «Интернета вещей», которые могут без помех взаимодействовать друг с другом.
Кто же из них сильнее, на кого ставить в этой борьбе?
Thread
В свое время Nest создавал Weave с намерением превращения его в открытый стандарт, который обеспечит работу своих устройств, а также, возможно, и миллионов других. Хорошо иметь стандарт, когда вы возглавляете процесс и уже имеете несколько миллионов установленных устройств. Может именно из-за этого Google и купил эту компанию за такие безумные деньги ($3.2 млрд.)
Судя по всему, Thread очень быстро может выйти на рынок и занять на нем лидирующее место, поскольку он использует существующие устройства (802.15.4), которые уже проданы в количестве десятков или сотен миллионов штук. По оценкам ABI Research, в 2016 году различные производители продадут 850 миллионов таких 2.5 Ггц-чипсетов. И Thread Group не ставит своей целью разработку новых чипов или аппаратной платформы, поскольку для продуктов, использующих IEEE 802.15.4, достаточно будет обновить программное обеспечение, чтобы сделать его совместимым с Thread.
AllSeen Alliance
Протокол на базе open source, получивший название AllJoyn, первоначально разрабатывался компанией Qualcomm и впервые был представлен в 2011 году. После нескольких лет незначительных достижений в разработке протокола, в 2013 году Qualcomm передала исходный код в Linux Foundation. Тогда Qualcomm и Linux Foundation и сформировали AllSeen Alliance, в который сейчас входят около 60 компаний, включая Cisco, Microsoft, LG и HTC.
AllJoyn предлагает инструменты для всего процесса соединения и работы устройств в сети WiFi. Производители могут использовать кроссплатформенный фреймворк AllJoyn для создания своих приложений, обеспечивающих работу устройств разного рода в WiFi-сети, используя готовые сервисы контроля и оповещений.
Стандарт отличается продвинутой системой защиты информации и низким энергопотреблением, поэтому многие относятся к нему как правильному выбору. Тем более, поскольку типичные проблемы, которые имеют другие протоколы, хорошо задокументированы, то AllJoyn имеет хорошие шансы это учесть и стать лучше, чем другие. И поскольку его основная задача заключается в обеспечении соединений любых устройств, операционных систем и сетевых протоколов, вряд ли он устареет, даже когда появятся новые технологии.
Open Interconnect Consortium
Такое «перекрестное опыление» симптоматично для данной ситуации, когда участники «войны» стараются усидеть одновременно на нескольких стульях: член этого консорциума компания Samsung одновременно является одним из основателей Thread Group.
В то же время некоторые члены консорциума OIC распространяют информацию о возникшем общем недоверии, которое связано с намерениями Qualcomm в отношении AllJoyn. Кроме того, Аймэд Сусу (Imad N. Sousou), глава Центра технологий open source компании Intel, заявил, что ни один проект, включая AllSeen Alliance, не показался OIC правильным направлением для разработки стандарта для IoT.
В свою очередь официальные лица Qualcomm, несмотря на одобрительное отношение Linux Foundation к OIC, публично опроверг, что члены AllSeen Alliance заморозили взаимодействие при разработке стандарта AllJoyn. Собственно, об этом свидетельствует и недавно опубликованная новость о выходе первого релиза AllJoyn. В общем, идет обычная конкурентная перепалка.
Разработка Open Interconnect Consortium все еще находится на очень ранней стадии, но пока единственная разница между этим проектом и AllSeen Alliance заключается в отторжении ими Qualcomm. OIC намерен создавать протокол, который целиком является проектом, в котором участвуют все члены консорциума. А Qualcomm несколько лет создавал AllJoyn самостоятельно, прежде чем передать его в AllSeen Alliance, и продолжает участвовать в процессе. Это-то и не нравится членам OIC. Возможно именно поэтому они и поспешили с объявлением о создании своего консорциума задолго до того, как у них появилось что-либо, чтобы сразу «застолбить поляну» без влияния Qualcomm.
Industrial Internet Consortium
В марте 2014 года компании Intel, Cisco, AT&T, GE и IBM объявили о создании Industrial Internet Consortium (IIC), который ставит своей целью разработку стандартов, предназначенных для промышленного использования Интернета вещей (Internet of Things, IoT).
IIC пока не опубликовал ни одной спецификации, но уже стал заметен растущий интерес других компаний к консорциуму и в июне к ним присоединилась Microsoft. Надо отметить, что в промышленности объединенные в сеть устройства использовались уже давно, задолго до возникшего интереса к т.н. Интернету вещей и соответствующей шумихе в прессе и социальных сетях. И образование в данный момент подобного консорциума было вполне очевидным шагом.
А что Apple? Google?
Правда, Google несколько менее напрягается по этому поводу, поскольку его собственное подразделение Nest возглавляет консорциум, разрабатывающий Thread. И вполне возможно, что в будущем Android будет интегрироваться с Thread. Кстати, будет интересно наблюдать, как будет реагировать весь обширный мир производителей Android-устройств на такой поворот в сторону Thread.
Apple, в свою очередь, особо не распространяется о новом рынке, на который он нацелился. Как, впрочем, это обычно и делает яблочная компания, искусственно подогревая интерес к своим проектам.
На кого поставить?
Ситуация пока непонятная и неочевидная, а расклад сил пока также не окончательный. Тем не менее, учитывая все вышесказанное, нам кажется несколько более прагматично настроенным и перспективным проект Thread. Поэтому мы решили здесь несколько подробнее рассказать о его возможностях и достоинствах.
Thread не только добавляет неограниченное расстояние для сети благодаря своей ячеистой топологии (а это слабое место WiFi, да и 6LoWPAN), он обладает также возможностями самовосстановления и самоуправления, которое обеспечивает доставку сигнала по наиболее эффективному маршруту в любое заданное время. Надо отметить, что в принципе ячеистая сеть может испытывать затруднения с большим количеством узлов, но Thread позволяет пользователям удалять и снова устанавливать устройства по своему желанию, без какого-либо ущерба для всей системы. При этом Thread легко объединяет в одну ячеистую сеть более 250 устройств.
Стандарт предполагает использование самой современной схемы аутентификации и AES-шифрования, позволяющие закрыть дыры в защите, которые существуют в других беспроводных протоколах. При этом безопасность обеспечивается как на уровне сети, так и на уровне приложений. Используются специальные коды продуктовой инсталляции, которые гарантируют, что в сети могут работать только авторизованные устройства. Поддерживается система криптографии с открытым ключом банковского уровня.
Впрочем, проблеме защиты сети уделяют повышенное внимание все вышеупомянутые группы разработчиков, и мы не будем утверждать, что Thread в чем-то их превосходит.
Подробная техническая документация, относящаяся к стандарту, будет опубликована позднее, обещают члены Thread Group. В настоящее время разрабатывается программа сертификации продуктов, которая будет открыта, как полагают, в первой половине 2015 года.
И прочие.
И несколько слов о других стандартах, на которых работает подавляющее количество систем домашней автоматизации и которые были признаны (но не их разработчиками, естественно) устаревшими. Мы приведем здесь доводы, которые используют в своих публикациях идеологи Thread.
ZigBee Pro требует использования сетевого управления для передачи трафика, и он не очень дружит с Интернет. ZigBee IP по возможностям уже ближе, но он не фокусируется на рынке домашней автоматизации, а относится скорее к «умным» измерительным устройствам. В нем существует ограничение количества узлов и протокол маршрутизации не очень эффективно работает при коммуникациях типа узел-узел.
Стандарт Z-Wave контролируется одним производителем микросхем и его ячеистая структура, по мнению конкурентов, не очень надежна. Он нуждается в сетевом управлении и имеет очень малую полосу пропускания.
Правда, с этими утверждениями не согласны разработчики этих стандартов, которые утверждают, что в арсенале Z-Wave и ZigBee уже присутствуют разработки, позволяющие развернуть сеть 6LoWPAN поверх нынешних устройств, и Thread в этом смысле не является первопроходцем.
Кстати, а вот Bluetooth может рассматриваться в ближайшем будущем как серьезный конкурент, особенно Bluetooth Smart (Bluetooth Low Energy или BLE), поскольку это повсеместно используемый стандарт, с малым энергопотреблением. Кроме того, благодаря технологиям CSRmesh, в ближайшее время он сможет применяться в ячеистых mesh-сетях.
Так что стрельба на этом фронте ведется со всех сторон и во все стороны.