История изменений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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