Когда я просматривал учебник по операционной системе роботов (ROS), я обнаружил, что большинство примеры кодов устанавливают для размера очереди издателя большее значение, например 1000. Я думаю, что это приводит к потере ответа узла в реальном времени.
С какой целью люди устанавливают такое большое значение?
Из документов ROS (http://wiki.ros.org/ROS/Tutorials/WritingPublisherSubscriber):
Издатель сообщений (производитель): «Второй параметр для Advertising() — это размер очереди сообщений, используемой для публикации сообщений. Если сообщения публикуются быстрее, чем мы можем их отправить, число здесь указывает, сколько сообщений нужно буферизовать, прежде чем выдавать немного подальше».
Подписчик сообщений: «Второй параметр функции subscribe() — это размер очереди сообщений. Если сообщения поступают быстрее, чем обрабатываются, это количество сообщений, которые будут помещены в буфер, прежде чем начнут отбрасываться самые старые сообщения. те."
Возможное объяснение: подумайте о проблеме потребитель-производитель.
Вы не можете гарантировать, что будете потреблять сообщения с той скоростью, с которой они приходят. Таким образом, вы создаете очередь, которая заполняется по мере поступления сообщений от отправителя (например, от какого-либо датчика). Плохой случай: если ваша программа задерживается в какой-то другой части, и вы не можете прочитать сообщения с той скоростью, с которой они прибыли, очередь увеличивается. Хороший случай: как только ваша другая вычислительная нагрузка уменьшится, вы сможете быстрее прочитать очередь и начать ее уменьшать. Если у вас есть свободное время, вы сократите размер очереди до нуля.
Итак, что касается вашего вопроса, если вы отправляете размер очереди на большое значение, вы можете гарантировать, что не потеряете сообщения. В простом примере у вас нет ограничений по памяти, поэтому вы можете делать все, что хотите, например, использовать много ГБ ОЗУ для создания большой очереди, и заверения всегда будут работать. Или, если вы создаете игрушечный пример для объяснения концепции, вы не хотите, чтобы ваша программа зависала по другим причинам.
Примером из жизни может быть сценарий официанта и кухни для мытья посуды. Предположим, что клиенты заканчивают трапезу, и официант уносит их грязную посуду, чтобы вымыть их на кухне. Ставит стол. Всякий раз, когда посудомойщик может, он подходит к столу, берет посуду и берет ее мыть. При нормальной работе таблица никогда не заполняется. Но если кто-то еще даст другое задание посудомойщику, стол начнет заполняться. До какого-то времени официант больше не может ставить посуду и оставляет столы грязными (проблема в системе). Но если там искусственно большой стол (скажем, 1000 квадратных единиц), то официант, скорее всего, выполнит свою работу, даже если посудомойка будет занята, учитывая, что через какое-то время он сможет вернуться к чистой посуде.
Хорошо, длинный ответ, но это может помочь понять очереди.
