doc: formatting minor update

doc/doxygen/chapters/350_scheduling_policy_definition.doxy

@@ -125,17 +125,17 @@ so that the scheduler does not need any additional mutex to protect its per-work
 In case the scheduler wants to access another scheduler's data, it should use
 starpu_worker_lock() and starpu_worker_unlock().
 
-Calling starpu_worker_lock(B) from a worker A will however thus make
-worker A wait for worker B to complete its scheduling method. That may be
+Calling \code{.c}starpu_worker_lock(B)\endcode from a worker \c A will however thus make
+worker \c A wait for worker \c B to complete its scheduling method. That may be
 a problem if that method takes a long time, because it is e.g. computing a
-heuristic or waiting for another mutex, or even cause deadlocks if worker B is
-calling starpu_worker_lock(A) at the same time. In such a case, worker B must
+heuristic or waiting for another mutex, or even cause deadlocks if worker \c B is
+calling \code{.c}starpu_worker_lock(A)\endcode	 at the same time. In such a case, worker \c B must
 call starpu_worker_relax_on() and starpu_worker_relax_off() around the section
 which potentially blocks (and does not actually need protection). While a worker
 is in relaxed mode, e.g. between a pair of starpu_worker_relax_on() and
 starpu_worker_relax_off() calls, its state can be altered by other threads: for
-instance, worker A can e.g. push tasks for worker B. In consequence, worker B
-must re-assess its state after starpu_worker_relax_off(B), such as taking
+instance, worker \c A can push tasks for worker \c B. In consequence, worker \c B
+must re-assess its state after \code{.c}starpu_worker_relax_off(B)\endcode, such as taking
 possible new tasks pushed to its queue into account.
 
 When the starpu_sched_policy::push_task method has pushed a task for another