shared.pm: Consistent spaces after dots

diff --git a/dist/threads-shared/lib/threads/shared.pm b/dist/threads-shared/lib/threads/shared.pm
index a4b77a8..5a24a98 100644 (file)
--- a/dist/threads-shared/lib/threads/shared.pm
+++ b/dist/threads-shared/lib/threads/shared.pm
@@ -406,7 +406,8 @@ the variable, and blocks until another thread does a C<cond_signal> or
 C<cond_broadcast> for that same locked variable.  The variable that
 C<cond_wait> blocked on is re-locked after the C<cond_wait> is satisfied.  If
 there are multiple threads C<cond_wait>ing on the same variable, all but one
-will re-block waiting to reacquire the lock on the variable. (So if you're only
+will re-block waiting to reacquire the
+lock on the variable.  (So if you're only
 using C<cond_wait> for synchronization, give up the lock as soon as possible).
 The two actions of unlocking the variable and entering the blocked wait state
 are atomic, the two actions of exiting from the blocked wait state and
@@ -454,16 +455,19 @@ be recalculated with each pass:
 =item cond_signal VARIABLE
 
 The C<cond_signal> function takes a B<locked> variable as a parameter and
-unblocks one thread that's C<cond_wait>ing on that variable. If more than one
+unblocks one thread that's C<cond_wait>ing
+on that variable.  If more than one
 thread is blocked in a C<cond_wait> on that variable, only one (and which one
 is indeterminate) will be unblocked.
 
 If there are no threads blocked in a C<cond_wait> on the variable, the signal
-is discarded. By always locking before signaling, you can (with care), avoid
+is discarded.  By always locking before
+signaling, you can (with care), avoid
 signaling before another thread has entered cond_wait().
 
 C<cond_signal> will normally generate a warning if you attempt to use it on an
-unlocked variable. On the rare occasions where doing this may be sensible, you
+unlocked variable.  On the rare occasions
+where doing this may be sensible, you
 can suppress the warning with:
 
   { no warnings 'threads'; cond_signal($foo); }