Apart from passing this mutex to the dynamic reconfigure server, shouldn't you be using it to prevent concurrent access of the gains by `updateCommand(...)` and `parameterReconfigureCallback(...)`?. In ros_control a single-threaded deployment is assumed, so no concurrency issues will arise; but this class might be used outside ros_control, and PID loop and gain updates might occur from different threads, right?.

On realtime systems mutices should be used with care, as you risk [priority inversions](http://en.wikipedia.org/wiki/Priority_inversion). So the `updateCommand(...)` or any other realtime-safe code block should never have to wait on a shared resource. If this can be guaranteed, you're good to go.

Another thing to keep an eye on is making Linux calls from realtime code (allocations, printf, certain time queries, etc.), but this is not the case in your PR.