Я разрабатываю сервер CORBA на C ++. По разным причинам (главным образом потому, что у меня есть другие задачи для выполнения в главном потоке), я хотел бы использовать неблокирующие API work_pending()
а также perform_work()
,
Тривиальный фрагмент кода будет:
while ( !shutdown )
{
if ( orb -> work_pending() )
orb -> perform_work();
if ( <other_requests> ) // my queue of non-corba activities
<process_request>;
}
Однако этот код использует процессор на 100%.
Я полагаю, что загрузка процессора на 100% неприемлема, даже на [многоядерном] сервере (не могли бы вы подтвердить это?), Поэтому мое решение этой проблемы заключается в улучшении цикла while с помощью sleep_until
:
while ( !shutdown )
{
system_clock::time_point now = system_clock::now();
while ( orb -> work_pending() )
orb -> perform_work();
while ( <other_requests> )
<process_request>;
std::this_thread::sleep_until( now + milliseconds( 10 ) );
}
С помощью этого решения я могу обеспечить максимальное время отклика 10 мс и низкую нагрузку на процессор в режиме ожидания.
Конечно, я могу настроить значение 10 мс, чтобы сбалансировать два параметра.
Мой вопрос:
НОТА: Я уже знаю, что могу использовать блокировку ORB::run()
+ многопоточность, но мой вопрос о неблокирующем API ORB::perform_work()
поэтому, пожалуйста, не тратьте время на то, чтобы спросить меня, почему я хочу использовать однопоточную архитектуру, и, пожалуйста, не предлагайте альтернативы ORB::perform_work()
, Я просто экспериментирую с разными архитектурами. Благодарю.
Что произойдет, если вы используете
CORBA::ORB::work_pending (ACE_Time_Value &tv)
вместо?
Я не уверен, правильно ли я понимаю документацию. Но похоже, что это ожидает, что самое большее произойдет ТВ секунд, а затем возвращается. Преимущество заключается в том, что по сравнению со сном в 10 мс, если что-то происходит в ORB в течение этих 10 мс, вы можете немедленно реагировать без какой-либо задержки. Конечно, если что-то случится в другие запросы у вас все еще есть задержка 10 мс …