-Among the above functions, the first two, namely barrier_init() and
-barrier_cacel() are used by experiment drivers. All barriers should be
-initialised by the experiment driver by calling barrier_init(). This function
-takes a name to identify the barrier, the quorum required for the barrier to be
-crossed and a notification callback for notifying the experiment driver when the
-barrier is crossed. The function barrier_cancel() cancels an initialised
-barrier and frees the resources allocated for it. This function can be called
-upon a initialised barrier before it is crossed.
-
-The remaining two functions barrier_wait() and barrier_wait_cancel() are used in
-the peer's processes. barrier_wait() connects to the local barrier service
-running on the same host the peer is running on and registers that the caller
-has reached the barrier and is waiting for the barrier to be crossed. Note that
-this function can only be used by peers which are started by testbed as this
-function tries to access the local barrier service which is part of the testbed
-controller service. Calling barrier_wait() on an uninitialised barrier barrier
-results in failure. barrier_wait_cancel() cancels the notification registered
-by barrier_wait().
+The remaining two functions GNUNET_TESTBED_barrier_wait() and
+GNUNET_TESTBED_barrier_wait_cancel() are used in the peer's processes.
+GNUNET_TESTBED_barrier_wait() connects to the local barrier service running on
+the same host the peer is running on and registers that the caller has reached
+the barrier and is waiting for the barrier to be crossed. Note that this
+function can only be used by peers which are started by testbed as this function
+tries to access the local barrier service which is part of the testbed
+controller service. Calling GNUNET_TESTBED_barrier_wait() on an uninitialised
+barrier results in failure. GNUNET_TESTBED_barrier_wait_cancel() cancels the
+notification registered by GNUNET_TESTBED_barrier_wait().