LINUX.ORG.RU

Data race

 ,


0

2

Санитайзер говорит о рейсах здесь, объясните мне пожалуйста - что здесь не так? Всё под мьютексом.

#include <mutex>
#include <thread>
#include <chrono>
#include <condition_variable>
#include <queue>
#include <memory>
using namespace std;

struct Mes {
	int data = 0;
	bool processed = false;
};

struct Test {
	mutex mtx;
	condition_variable cv;
	queue<weak_ptr<Mes>> mes_queue;
	int read();
	bool check();
} t;

int Test::read()
{
	auto sh_ptr = make_shared<Mes>();
	unique_lock lck{mtx};
	mes_queue.push(sh_ptr);
	while (! cv.wait_for(lck, 1s, [&sh_ptr](){
				return sh_ptr->processed == true;})  &&  true);
	return sh_ptr->data;
}

bool Test::check()
{
	scoped_lock lck{mtx};

	bool ret = mes_queue.size();
	while (mes_queue.size()) {
		if (shared_ptr<Mes> mes = mes_queue.front().lock()) {
			mes->data = 5;
			mes->processed = true;
		}
		mes_queue.pop();
	}
	cv.notify_all();
	return ret;
}

void read_th() {
	while (true) {
		t.read();
		this_thread::sleep_for(200ms);
	}
}

void check_th() {
	while (true) {
		t.check();
		this_thread::sleep_for(200ms);
	}
}

int main() {
	jthread tr{read_th};
	jthread tc{check_th};
}

$ g++ -pthread -std=c++20 -fsanitize=thread test.cc

Выхлоп санитайзера весьма обилен, вставил сюда, но главное то, что жалобы на рейсы в полностью валидном коде (на мой взгляд).

★★
Ответ на: комментарий от alysnix

а будит и встает в ожидание - это вопрос не отдельный, а принципиальный!

Чем? Вы походу даже не догадываетесь что есть вполне себе практические задачи оптимальное решение которых предполагает что consumer (aka читатель) вообще никогда не спит. Их прибивают гвоздями к изолированным ядрам убирая оттуда всё лишнее (включая прерывания) и гоняют в busy-wait loops. А синхронизация тем не менее нужна. И как сюда вписываются Ваши любимые мьютексы??! Да они там смерти подобны. То что Вы никогда не имели дело с low-latency задачами вовсе не означает что и остальные тоже. И фундаментальные примитивы синхронизации Вам дали абсолютно правильные, хотя бы потому что именно так работает современное железо. А мьютекс в этом контексте очень высокоуровневый примитив требующий поддержки со стороны ядра. Продолжайте др^wмолиться на него и дальше. Я устал если честно - Вы как будто с Луны свалились, чес слово…

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

Чем? Вы походу даже не догадываетесь что есть вполне себе практические задачи оптимальное решение которых предполагает что consumer (aka читатель) вообще никогда не спит. Их прибивают гвоздями к изолированным ядрам убирая оттуда всё лишнее (включая прерывания) и гоняют в busy-wait loops.

«вполне практические задачи», никоим образом не сформулированные, не несут никакого практического смысла в дискуссии. может они порождение вашей фантазии, проверить это никак не возможно…

а я вот так и думал, что вы сведете все к поллингу. только это батенька не имеет к тредам ни малейшего отношения, потому что треды должны спать и ждать ивентов…экономьте хотя бы электроэнергию уже в эпоху глобального потепления.

я честно говоря не решаюсь себе представлять программера, что пишет ну какую-то системку с десятком тредов, и «приколачивает их к ядрам»…которых может быть всего 2-4.

то есть десяток консюмеров у вас сидят в поллинге, «приколоченые» к 8 ядрам, вентилятор воет, нагрузка 100 процентов… а двум из них ядер-то нет, поскольку все остальные с приколоченным поллингом. причем в полинге сидят они зря, потому что возможно, что нужный ивент никогда не произойдет.

это все чего вы достигли своими концепциями.

вопрос - вам надо проц с 16 ядрами, чтобы решить нелегкую задачу с 10 консюмерами? а если их будет 100, вам кластер надо купить?

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

«вполне практические задачи», никоим образом не сформулированные, не несут никакого практического смысла в дискуссии. может они порождение вашей фантазии, проверить это никак не возможно…

а я вот так и думал, что вы сведете все к поллингу. только это батенька не имеет к тредам ни малейшего отношения, потому что треды должны спать и ждать ивентов.

Что я могу сказать… Чем больше таких людей как Вы, тем большую ценность я представляю как специалист. Продолжайте в том же духе, пожалуйста. I’m out.

bugfixer ★★★★★
()
Ответ на: комментарий от alysnix

вопрос - вам надо проц с 16 ядрами, чтобы решить нелегкую задачу с 10 консюмерами? а если их будет 100, вам кластер надо купить?

Не удержался: на тех машинках которые выделены под мои задачи нынче от 48 ядер, и их десятки. И электричество которое я жгу таки окупается с лихвой. Теперь реально out…

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

Чем больше таких людей как Вы, тем большую ценность я представляю как специалист. Продолжайте в том же духе, пожалуйста. I’m out.

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

Просто почитайте как устроены планировщики, треды и обьекты синхронизации и не гоните пургу.

alysnix ★★★
()
Ответ на: комментарий от alysnix

Просто почитайте как устроены планировщики, треды и обьекты синхронизации и не гоните пургу.

Ха. И ещё 3 раза «ха». Повзрослейте уже…

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

Ха. И ещё 3 раза «ха». Повзрослейте уже…

как могут сотни тредов сидеть в ожидании(а в реальной системе это так и есть), крутить ваши поллинги(что есть абсолютный антипаттерн, везде прописанный), а нагрузка проца при этом полпроцента? вы не верите сисмону какому-нить? вы не верите вашему еле вращающемуся вентилятору на проце?

тогда вы верите только в свои фантазии.

alysnix ★★★
()
Ответ на: комментарий от alysnix

как могут сотни тредов сидеть в ожидании(а в реальной системе это так и есть), крутить ваши поллинги(что есть абсолютный антипаттерн, везде прописанный), а нагрузка проца при этом полпроцента?

Не знаю, зачем я это делаю, но… Задача - добиться устойчивого времени реакции на сообщение порядка 10 микро секунд. Ваше решение? Студия ждёт.

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от bugfixer

Задача - добиться устойчивого времени реакции на сообщение порядка 10 микро секунд. Ваше решение? Студия ждёт.

это вопрос ни о чем. не указаны ни железо, ни ос, ни характер «сообщения», ни характер «реакции», ни средняя загрузка системы. и все эти факторы влияют на ответ.

для каких-то случаев и ситуаций… время реакции будет вообще наносекунды, для других - куда дольше.

хотите хардкорного жесткого рилтайма - ставьте плис. короче сначала почитайте про low latency системы или архитектуры, как железа так и по, а потом вопрос задавайте.это обширная тема, и так просто, ее касаясь, вопрос ставить нельзя.

но сразу скажу - это не имеет к поллингу ни малейшего отношения, если вы пытаетесь его как-то оправдать для применения.

по простой причине. если N процессов, ну или тредов, находятся в полинге, ядер меньше чем N, то все равно треды будут вытесняться, и какое-от время в полллинге не быть. и если в это время придет событие которое они типа поллят, то среагирует такой тред на событие только когда ему дадут ядро. и это время будет определяться частотой переключения тредов и их и числом.

допустим тредов 10, и все в полинге - а ядро одно. тогда скорость реакции в среднем - квант времени работы треда * N/2.

вот если ядро одно, квант времени 1 мс, тредов 10(НА ВСЮ ЖЕЛЕЗО!!!), то если они даже сидят в поллинге, то время среднее время реакции будет 5 мс. и загрузка проца 100 проц.

а на правильной системе время реакции будет определяться временем переключения тредов(это вопросы к реализации планировщика) и менеджментом приоритетов тредов. и будет куда меньше, чем даже если вы будете поллить. и загрузка проца - ноль! от есть правильное решение бьет ваши «взрослодядечковые» методологии, по всем направлениям.

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

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

это вопрос ни о чем. не указаны ни железо, ни ос, ни характер «сообщения», ни характер «реакции»

Железо Вам купят любое, какое попросите. Время реакции - с момента TCP packet in до TCP packet out на network interface. Не уходите от темы. И это реальная прикладная задача.

bugfixer ★★★★★
()
Ответ на: комментарий от alysnix

а на правильной системе время реакции будет определяться временем переключения тредов

Вот, вот оно. Вы отдаёте себе отчёт насколько это долго?? Повторюсь - мы живём в мире где микро (а иногда и нано) секунды имеют значение. Успели - «сорвали куш», не успели - «Вас порвали». И в этом контексте Ваше благосостояние напрямую зависит от того насколько Вы хороши. Подумайте об этом, и только потом начинайте проповедовать свою истерику на тему mutex и тому подобного.

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

Железо Вам купят любое, какое попросите. Время реакции - с момента TCP packet in до TCP packet out на network interface. Не уходите от темы. И это реальная прикладная задача.

вы опять не специфицируете задачу. непонятно что делают с пакетом с момента прихода до момента отправки. может его анализируют, переделывают, проверяют, сравнивают с чем-то, блокируют или еще что-то.

на такие задачи ставят плис, и разрабатывают свое железо, если решать их харкорно. это первый вариант.

второй вариант - железо свое с процом общего применения с некой осью жесткого рилтайма.

третий вариант - железо не свое, а на горбушке купили, ось общего применения - тогда это надо мануалы читать как эту ось заставить работать с low latency. все будет зависеть - как она устроена и что позволяет в области low latency.

но поллинг тут вообще не причем. в общем случае это будет работать намного медленнее(и полностью занимать проц или ядро)!!! чем ось жесткого рилтайма. я говорю про общий случай.

и не надо выдавать частные случаи за общие.

alysnix ★★★
()
Ответ на: комментарий от alysnix

… вы опять не специфицируете задачу.

Раз о наносекундах речь идет, то скорее всего - обработка биржевой информации …

anonymous
()
Ответ на: комментарий от bugfixer

Вот, вот оно. Вы отдаёте себе отчёт насколько это долго??

это недолго. это десяток ассемблерных команд для кернела жесткого рилтайма. если постараться, то 3-5. там всего лишь спасаются регистры текущего треда, и восстанавливаются регистры старого.

для процов где поддерживается пуш/поп сразу многих регистров одной командой, это две команды. и это будет работать на порядок! быстрее чем ваш поллинг.

полинг будет быстрей только если тред ваш не вытесняется физически с ядра. но если его вытеснят - то вернут ему ядро через МНОГО большее время, чем исполнение десятка команд на асме.

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

но поллинг тут вообще не причем. в общем случае это будет работать намного медленнее(и полностью занимать проц или ядро)!!! чем ось жесткого рилтайма.

Вы реально ещё дитё, не обижайтесь.

и не надо выдавать частные случаи за общие.

Это как раз Вы обобщаете, где не стоило бы. Учите тех часть.

bugfixer ★★★★★
()
Ответ на: комментарий от alysnix

на такие задачи ставят плис, и разрабатывают свое железо, если решать их харкорно. это первый вариант.

Расскажите мне, ага.

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

Вы реально ещё дитё, не обижайтесь.

ответ не по существу.

оцените среднее время реакции на ивент, если у вас два треда равного приоритете в поллинге, ядро одно, и квант времени работы треда - 1 мс.

давайте число. и посмотрим сколько команд процессор исполнит за это время, при частоте 1 ггц и одном такте на команду.

alysnix ★★★
()
Ответ на: комментарий от alysnix

оцените среднее время реакции на ивент, если у вас два треда равного приоритете в поллинге, ядро одно, и квант времени работы треда - 1 мс.

Это не реалистичная задача. Точнее не та задача которую мы решаем. Я хочу иметь выхлоп за микро секунды, и это всё что меня интересует. И я всё еще жду вашей версии оптимального решения.

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

Это не реалистичная задача.

в рамках ваших советов, как ПРАВИЛЬНО писать многопоток, другой постановки вопроса и быть не может. у вас ВСЕ треды сидят в поллинге, потому что ничто иное вы не рекомендовали.

потому и предложена простейшая задачка, два треда, ядро одно, поллинг. скорость реакции? вы ее не может решить чтоли?

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 2)
Ответ на: комментарий от alysnix

в рамках ваших советов, как ПРАВИЛЬНО писать многопоток

Где?? Я всего лишь утверждал что Ваш выбор of fundamentals мягко говоря не правилен. И в общем случае не покрывает потребности никак. С этого всё и началось.

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

С этого всё и началось.

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

так. ладно. решаем сами. два треда, ядро одно, квант - 1ms. лучшее время реакции - 0. это когда тред поллит в данный момент. худшее время реакции, 1 ms - это когда этот тред вытеснили, и только что переключились на другой.

в половине случаев(при равномерном распределении ивентов) будет ноль, в половине - в среднем 1/2 кванта. итого 1/4 кванта - среднее время реакции. то есть 250 мкс. это среднее.

за какое время правильный планировщик рилтайма может переключить треды. оценочно берем 10 команд на переключение. при частоте 1 ггц это 10 нс! это разумеется оценочные рассчеты.

итого, что мы имеем. поллинг - 250 мкс среднее время. правильный рилтайм - 10 нс.

скорбим всем селом, над вашей «архитектурой».

alysnix ★★★
()
Ответ на: комментарий от alysnix

скорбим всем селом, над вашей «архитектурой».

Мы Вас ждём. Вы приходите, не стесьняйтесь. С живыми деньгами желательно. А там посмотрим кто чего стоит.

bugfixer ★★★★★
()
Ответ на: комментарий от alysnix

так. ладно. решаем сами. два треда, ядро одно, квант - 1ms.

Вы ошиблись этак на 3 порядка. Речь про микро, не милли.

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

С живыми деньгами желательно. А там посмотрим кто чего стоит.

сравнивайте не деньги, а сравнивайте время. 250 мс и 10 нс.

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

там это решается в пространсте рутин, активируемых прерываниями. по сути это хуки, вызываемые сразу контроллером прерываний. это задачи наивысшего приоритета, они выполняются прям на стеке текущего треда, и предназначены для мгновенной обработки ивентов с внешних устройств например. вот например пакетов.

alysnix ★★★
()
Ответ на: комментарий от alysnix

там это решается в пространсте рутин, активируемых прерываниями. по сути это хуки, вызываемые сразу контроллером прерываний. это задачи наивысшего приоритета, они выполняются прям на стеке текущего треда, и предназначены для мгновенной обработки ивентов с внешних устройств например. вот например пакетов

Расскажите мне. Ага. (Кажется повторяюсь).

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

Вы ошиблись этак на 3 порядка. Речь про микро, не милли.

покажите в какой оси квант времени 1 мкс по дефолту.

и даже это вас не спасет. будет тогда ваше латенси не 250мкс, а 250 нс. это в 25 раз больше чем 10 нс.

alysnix ★★★
()
Ответ на: комментарий от alysnix

сравнивайте не деньги, а сравнивайте время. 250 мс и 10 нс.

Вы уже купили свой первый поршик/ферарри? Тогда пожалуйста не учите народ как жить.

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

Расскажите мне. Ага. (Кажется повторяюсь).

а давайте вы будете сами это читать.

alysnix ★★★
()
Ответ на: комментарий от alysnix

два треда, ядро одно

А можно наоборот: один тред, два ядра? И (аппартный) планировщик раскидывает команды по ядрам беспорядочно (OoO).

А то как-то уныло - вытесняющая многозадачность на одном процессоре

anonymous
()
Ответ на: комментарий от anonymous

А что не поделили то?

У товаристча очень забавные представления о примитивах синхронизации, да и о том как устроен этот мир тоже. Я бы даже не парился, но это же с завидной упоротостью в массы несут. Ну и «не удержались мы».

bugfixer ★★★★★
()
Ответ на: комментарий от anonymous

А можно наоборот: один тред, два ядра?

нельзя. потому, что число тредов превышает число ядер на порядок, и не менее. потому, что надо учитывать ВСЕ треды, работающие на вашем железе, в данный момент, а не только треды вашего процесса.

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от bugfixer

Я бы даже не парился, но это же с завидной упоротостью в массы несут. Ну и «не удержались мы».

с завидной упоротостью вы рекламируете поллинг для жесткого рилтайма, даже когда вам сунули под нос разницу в несколько порядков по латенси в реальной ситуации, для поллинга и нормального решения.

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

с завидной упоротостью вы рекламируете поллинг для жесткого рилтайма,

НЕТ. Совсем нет. Я только утверждаю что оригинальный выбор примитивов мягко говоря ущербен.

даже когда вам сунули под нос разницу в несколько порядков по латенси в реальной ситуации, для поллинга и нормального решения.

Очевидно что Вы никогда этим не занимались. Не позорьтесь.

bugfixer ★★★★★
()
Ответ на: комментарий от anonymous

Гуглим «когда полезен polling» …

Я люблю пополлировать лор.

anonymous
()
Ответ на: комментарий от anonymous

Гуглим «когда полезен polling» …

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

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

alysnix ★★★
()
Ответ на: комментарий от bugfixer

Что-то никаких полезняшек не выпадает… Не туда смотрю?

Но ваш оппонент утверждает, что вы пишите о пользе pooling?
Или о чем речь?

anonymous
()
Ответ на: комментарий от anonymous

Но ваш оппонент утверждает, что вы пишите о пользе pooling? Или о чем речь?

Я утверждаю что polling зачастую единственный рабочий вариант. Более того - оппонент до сих пор не смог привести альтернативы дающей разумные результаты, даже близко.

bugfixer ★★★★★
()
Ответ на: комментарий от alysnix

и число активных тредов на ядре.

Это как? Что я пропустил?

bugfixer ★★★★★
()
Ответ на: комментарий от anonymous

Для форумчан.

Гуглим «+polling сеть» …

anonymous
()
Ответ на: комментарий от anonymous

чтобы понять вред от поллинга, надо понимать, как рантаймовый планировщик ставит треды в ожидание ивентов, и как их будит, когда такой ивент пришел.

а делается это так. есть обьект ивент. в нем есть очередь тредов, которые его ждут - список указателей на дескрипторы ожидающих тредов.

вот есть ивент A. это обьект со списком внутри

когда текущий тред T говорит - жду ивента А, планировщик немедленно заносит указатель на этот тред Т в список ожидающих ивенту А. и переключает на другой тред, если список активных не пуст.

как только какой-то тред сказал - A.raise_event(), то есть возбудил ивент A, планировщик берет первый тред из списка ожидающих из ивента A, и переключается на него. то есть время «реакции» - это скорость выборки первого треда из списка, и переключения на него.

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

но если вы поллите, и вас переключили, то вы вернетесь к поллингу только через N-1 таймслайсов, где N - число активных тредов на ядре. а это будет доолго, по сравнению с неполингом.

при неполинге вы б уже сидели в списке ожидающих на ивенте, и при его возникновении, вас бы возобновили.

при поллинге и переключении во время его, вы не находитесь в списке ожидающих на ивенте, и сможете принять ивент, только когда вернетесь к поллингу. то есть через N таймслайсов.

то есть думая, что поллинг это быстро… вы значительно ухудшили латенси.

alysnix ★★★
()
Ответ на: комментарий от anonymous
Ещё один технический вопрос. Знаю, что на OpenKyiv 2008 вы активно дискутировали с выступавшим там Михаилом Белопуховым (проект OpenBSD) о том, почему сейчас разработчики FreeBSD уходят от polling’а сетевых карт.

Итак, многим будет интересно узнать, в самом деле, почему такая известная техника как polling сейчас уже не перспективна, можно пояснить нашим читателям?

Текущая архитектура FreeBSD обрабатывает прерывания от устройств, и, в частности, сетевых карт, в специально запущенных для этого нитках. Если нить блокирована, единственное действие кода обработки прерывания — разблокировка этой нити. Для иллюстрации, вот кусочек вывода ps auxww на машине, с которой я это пишу:

root 218 0.0 0.0 0 8 ? WL 9:46PM 0:00.79 [irq20: rl0 fwohci0] root 220 0.0 0.0 0 8 ? WL 9:46PM 0:05.69 [irq22: skc0 ath0]
Далее, почти все современные сетевые адаптеры для 1000baseTx имеет feature называемую «interrupt coalescing», задерживающую вызов прерывания до заполнения Rx-кольца адаптера.

Третье обстоятельство — это так называемый direct dispatch. Если вы помните, упомянутый вами докладчик OpenBSD говорил на конференции об отдельном процессе netisr, предназначенном для обработки Rx-фреймов. Причина существования netisr - тот факт, что прерывание от Rx может прийти в момент, когда процессор уже выполняет сетевой код, и полная обработка пакета из interrupt handler привела бы к рекурсивному входу в сетевой стек. Альтернативой было бы поднять приоритет процессора до splnet (в терминах OpenBSD), но это бы означало, что прерывания будут блокированы на длительное время.

Но, поскольку FreeBSD выполняет настоящий обработчик прерывания в отдельной нитке, то netisr не нужен. Вся обработка входящего пакета может произойти без дорогостоящего переключения контекста.

Это и есть direct dispatch. Direct dispatch включен по умолчанию на FreeBSD >= 7: net.isr.direct: 1

Нетрудно видеть, что комбинация всех трех упомянутых архитектурных элементов эквивалентна polling’у и даже эффективнее его. Конечно, пока ещё есть старые сетевые карты, для которых polling выигрывает, но тенденция развития современных сетевых карт состоит в том, что direct dispatch уже не хуже и при этом более естественен, чем polling.
anonymous
()
Ответ на: комментарий от anonymous

Интересная статья

это какая-то кривая архитектура на самом деле. и спасает тут скорее всего то, что сетевые пакеты приходят не так часто, в силу того, что сеть это вам не внутренняя память и не проц с гигагерцами. и ос там - фрибсд.

по хорошему(как всегда и делается) там при приходе данных должен возникать некий интеррапт, и запускаться его обработчики, а потом пакет должен побрасыватся каким-нить драйверам, что будут делать свое дело с высоким приоритетом.

Как заявляют разработчики — они уходят от polling’a. Вот выдержка из письма от Константина Белоусова

вот это и надо читать

alysnix ★★★
()
Ответ на: комментарий от alysnix

планировщик берет первый тред из списка ожидающих из ивента A, и переключается на него

Вот прям, так сразу, игнорируя очередь более приоритетных активных задач?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.