Please ask about problems and questions regarding this tutorial on answers.ros.org. Don't forget to include in your question the link to this page, the versions of your OS & ROS, and also add appropriate tags.

Priorities

Levels

The ecl defines abstract levels to standardise the priority api across platforms. These are defined in the Priority enum which has values for:

   1 using ecl::BackgroundPriority;
   2 using ecl::LowPriority;
   3 using ecl::NormalPriority;
   4 using ecl::HighPriority;
   5 using ecl::CriticalPriority;
   6 // Posix real time scheduling priorities only (not available on windows).
   7 using ecl::RealTimePriority4;
   8 using ecl::RealTimePriority3;
   9 using ecl::RealTimePriority2;
  10 using ecl::RealTimePriority1; // highest priority
  11 

Setting

The threading classes typically allow configuration from their methods, however you can set/reset the priority for the current thread at any point by calling set_priority.

   1 ecl::set_priority(ecl::BackgroundPriority);

Process Priority

Calling the set_priority function in the main thread will configure your process' priority (this setting should get passed on to its children by default on most systems).

Higher Level Priorities

Typically linux systems do not come pre-configured for higher level priorities - typically anything higher than NormalPriority requires special permissions. If these are not set, the set_priority function will either throw an exception (in debug mode) or return false when not granted permission to do so.

   1 try {
   2     set_priority(RealTimePriority4);
   3 } catch ( const StandardException &e ) { 
   4     std::cout << "Do not have permission for the higher level priorities." << std::endl;
   5 }   

To configure your system to do so, edit /etc/security/limits.conf. An example of editing this file for a user snorri to enable both realtime priorities to level 95 and the maximum niceness setting on a typical linux box:

   1 snorri          -       nice            -20
   2 snorri          -       rtprio           95

Real Time Scheduling

This is just some notes (for curiosity) with reagards to priorities corresponding to RealTimePriority4 or above.

Posix systems will often have various real time priority scheduling capabilities. Note that this is not real time linux. Rather, threads working under this sort of scheduling are pulled from the usual userland scheduling manager where they are typically assigned a niceness value.

A single thread pulled into real time scheduling is guaranteed to get cpu time whenever it needs it. There is no weighting, or favours done for threads who've waited a long time. It's a guarantee. The rest of the threads on the system will then be spliced time when the real time thread is sleeping or idle.

Be careful with this! We've found it can greatly enhance control loops for motors to ensure that they work sufficiently in most systems without the need to go to real time linux. However you must take care that these threads don't start starving the remaining threads on your system.

In addition, a thread working at RealTimePriority2 is guaranteed to get cpu time over a thread working at RealTimePriority1. Two threads at the same real time priority level will go into a round robin.

You can check that your threads are running at realtime priority by running the following command:

> ps -C <process_name> -m -o pid,rtprio,ni,pri,vsize,rssize,pmem,pcpu,comm