diff --git a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki
index 72ca07f1..b436bc18 100644
--- a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki
+++ b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki
@@ -195,12 +195,12 @@ After an asynchronous feature call, the execution of the client proceeds immedia
 
 First, every feature call is either a synchronous feature call or an asynchronous feature call. For a particular call, the following rules determine which it is:
 
-A feature call is synchronous in the following cases:
+A feature call is '''synchronous''' in the following cases:
 # It is a non-separate call.
 # It is a separate call to a query.
 # It is a feature call which has at least one actual argument which is a separate argument of the enclosing routine.
 
-A feature call is asynchronous in the following case:
+A feature call is '''asynchronous''' in the following case:
 # It is a separate call to a command.
 
 Let’s look a little closer at those cases determining synchronous calls. 
diff --git a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/barbershop.wiki b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/barbershop.wiki
index eeed14a2..6aa5ca1f 100644
--- a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/barbershop.wiki
+++ b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/barbershop.wiki
@@ -26,6 +26,23 @@ The <code>SHOP</code> includes features <code>enter</code> and <code>leave</code
 
 A typical customer lives in this way: As long as he still needs haircuts, he repeatedly does the following steps: He tries to enter the shop. If he's unsuccessful because all the chairs are occupied, he goes off for a while (in the implementation, his processor sleeps and then comes to the end of this step). If he is able to enter the shop, then he puts himself in the queue for a haircut. Once his haircut is complete, he reduces his number of haircuts needed by one, and leaves the shop.
 
+One thing that you might find curious about this example is the feature <code>do_hair_cut</code> in class <code>BARBER</code>. This feature is called by a customer when the barber becomes available to cut the customer's hair. <code>do_hair_cut</code> is a function that returns a <code>BOOLEAN</code>. If you look at the source code for <code>do_hair_cut</code>, you'll see that the routine cannot complete with any result other than <code>True</code> ... and this may seem odd. 
+
+<code>
+    do_hair_cut (an_id: INTEGER): BOOLEAN
+            -- Called from a customer who wants to get hair cut
+        require
+            an_id >= 0
+        do
+            (create {EXECUTION_ENVIRONMENT}).sleep (hair_cut_time * 1000000)
+            result := true
+        end
+</code>
+
+Couldn't a function that always returns the exact same predictable result be safely made a procedure? Certainly it could. However, there is a SCOOP oriented reason for this routine being a function rather than a procedure. 
+
+<code>{BARBER}.do_hair_cut</code> is a function in order to become synchronous. Remember that a [[Concurrent Eiffel with SCOOP#Separate types and separate calls|separate call]] which is a query is always a [[Concurrent Eiffel with SCOOP#Synchronous and asynchronous feature calls|synchronous call. In the case of the customer, he needs to leave the shop only after his haircut is complete. Therefore, the query <code>do_hair_cut</code> will be synchronous and ensure that the haircut is complete before the customer leaves the shop.
+