Fixed yardoc.

Author: jdantonio

doc/channel.md

@@ -176,7 +176,7 @@ fibonacci(c, quit)
 
 ## Closing and Iterating Over Channels
 
-Newly created channels are in an "open" state. Open channels can receive values via `put` operations. When a program is done with a channel it can be closed by calling the {#close} method. Once a channel is closed it will no longer allow values to be `put`. If the channel is buffered and values are in the buffer when the channel is closed, the remaining values can still be removed via `take` operations.
+Newly created channels are in an "open" state. Open channels can receive values via `put` operations. When a program is done with a channel it can be closed by calling the `#close` method. Once a channel is closed it will no longer allow values to be `put`. If the channel is buffered and values are in the buffer when the channel is closed, the remaining values can still be removed via `take` operations.
 
 The `Channel` class implements an {#each} method which can be used to retrieve successive values from the channel. The `each` method is a blocking method. When the channel is open and there are no values in the buffer, `each` will block until a new item is `put`. The `each` method will not exit until the channel is closed.
 

doc/synchronization.md

@@ -7,7 +7,7 @@
 Provides common parent for all objects which need to be synchronized or be using other synchronization tools. It provides:
 
 -   Synchronized block
--   Methods for waiting and signaling 
+-   Methods for waiting and signaling
 -   Volatile fields
 -   Ensure visibility of final fields
 -   Fields with CAS operations
@@ -49,7 +49,7 @@ private
 def ns_compute
   ns_compute_reduce ns_compute_map
 end
-``` 
+```
 where `compute` defines how is it synchronized and `ns_compute` handles the behavior (in this case the computation). `ns_` methods should only call other `ns_` methods or `pr_` methods. They can call normal methods on other objects, but that should be done with care (better to avoid) because the thread escapes this object while the lock is still held, which can lead to deadlock. That's why the `report` method is called in `compute` and not in `ns_compute`.
 
 `pr_` methods are pure functions they can be used in and outside of synchronized blocks.
@@ -60,16 +60,16 @@ Sometimes while already inside the synchronized block some condition is not met.
 
 To fulfill these needs there are private methods:
 
--   `ns_wait` {include:Concurrent::Synchronization::AbstractObject#ns_wait}
--   `ns_wait_until` {include:Concurrent::Synchronization::AbstractObject#ns_wait_until}
--   `ns_signal` {include:Concurrent::Synchronization::AbstractObject#ns_signal}
--   `ns_broadcast` {include:Concurrent::Synchronization::AbstractObject#ns_broadcast}
+-   `ns_wait` {include:Concurrent::Synchronization::AbstractLockableObject#ns_wait}
+-   `ns_wait_until` {include:Concurrent::Synchronization::AbstractLockableObject#ns_wait_until}
+-   `ns_signal` {include:Concurrent::Synchronization::AbstractLockableObject#ns_signal}
+-   `ns_broadcast` {include:Concurrent::Synchronization::AbstractLockableObject#ns_broadcast}
 
 All methods have to be called inside synchronized block.
 
 ## Volatile fields
 
-`Synchronization::Object` can have volatile fields (Java semantic). They are defined by `attr_volatile :field_name`. `attr_volatile` defines reader and writer with the `field_name`. Any write is always immediately visible for any subsequent reads of the same field. 
+`Synchronization::Object` can have volatile fields (Java semantic). They are defined by `attr_volatile :field_name`. `attr_volatile` defines reader and writer with the `field_name`. Any write is always immediately visible for any subsequent reads of the same field.
 
 ## Ensure visibility of final fields
 
@@ -83,7 +83,7 @@ class AbstractPromise < Synchronization::Object
     ensure_ivar_visibility!
   end
   # ...
-end  
+end
 ```
 
 ###  Naming conventions
@@ -112,10 +112,10 @@ class Event < Synchronization::Object
     self
   end
   # ...
-end  
+end
 ```
 
-Operations on `@Touched` field have volatile semantic. 
+Operations on `@Touched` field have volatile semantic.
 
 ## Memory model
 
@@ -125,7 +125,7 @@ When writing libraries in `concurrent-ruby` we are reasoning based on following
 
 The memory model is constructed based on our best effort and knowledge of the 3 main Ruby implementations (CRuby, JRuby, Rubinius). When considering certain aspect we always choose the weakest guarantee (e.g. local variable updates are always visible in CRuby but not in JRuby, so in this case JRuby behavior is picked). If some Ruby behavior is omitted here it is considered unsafe for use in parallel environment (Reasons may be lack of information, or difficulty of verification).
 
-This takes in account following implementations: 
+This takes in account following implementations:
 
 -   CRuby 1.9 - 2.2 (no differences found)
 -   JRuby 1.7
@@ -139,10 +139,10 @@ We are interested in following behaviors:
 
 ### Variables
 
--   **Local variables** - atomic assignment (only Integer and Object), non-volatile. 
+-   **Local variables** - atomic assignment (only Integer and Object), non-volatile.
     -   Consequence: a lambda defined on `thread1` executing on `thread2` may not see updated values in local variables captured in its closure.
     -   Reason: local variables are non-volatile on Jruby and Rubinius.
--   **Instance variables** - atomic assignment (only Integer and Object), non-volatile. 
+-   **Instance variables** - atomic assignment (only Integer and Object), non-volatile.
     -   Consequence: Different thread may see old values; different thread may see not fully-initialized object.
     -   Reason: local variables are non-volatile on Jruby and Rubinius.
 -   **Constants** - atomic assignment, volatile.

lib/concurrent/synchronization/object.rb

@@ -20,7 +20,7 @@ module Synchronization
     # @!macro [attach] synchronization_object
     #
     #   Safe synchronization under any Ruby implementation.
-    #   It provides methods like {#synchronize}, {#wait}, {#signal} and {#broadcast}.
+    #   It provides methods like `#synchronize`, `#wait`, `#signal` and `#broadcast`.
     #   Provides a single layer which can improve its implementation over time without changes needed to
     #   the classes using it. Use {Synchronization::Object} not this abstract class.
     #