perlthrtut.pod (based on perl-current@29766)

diff --git a/pod/perlthrtut.pod b/pod/perlthrtut.pod

index c0ad915..a6b0b18 100644 (file)
--- a/pod/perlthrtut.pod
+++ b/pod/perlthrtut.pod
@@ -117,7 +117,7 @@ step back a bit and think about what you want to do and how Perl can
 do it.
 
 However, it is important to remember that Perl threads cannot magically
-do things unless your operating system's threads allows it. So if your
+do things unless your operating system's threads allow it. So if your
 system blocks the entire process on C<sleep()>, Perl usually will, as well.
 
 B<Perl Threads Are Different.>
@@ -621,7 +621,7 @@ threads to have the I<lock> at any one time.
 =head2 Basic semaphores
 
 Semaphores have two methods, C<down()> and C<up()>: C<down()> decrements the resource
-count, while up() increments it. Calls to C<down()> will block if the
+count, while C<up()> increments it. Calls to C<down()> will block if the
 semaphore's current count would decrement below zero.  This program
 gives a quick demonstration:
 
@@ -690,8 +690,8 @@ of these defaults simply by passing in different values:
 If C<down()> attempts to decrement the counter below zero, it blocks until
 the counter is large enough.  Note that while a semaphore can be created
 with a starting count of zero, any C<up()> or C<down()> always changes the
-counter by at least one, and so C<$semaphore->down(0)> is the same as
-C<$semaphore->down(1)>.
+counter by at least one, and so C<< $semaphore->down(0) >> is the same as
+C<< $semaphore->down(1) >>.
 
 The question, of course, is why would you do something like this? Why
 create a semaphore with a starting count that's not one, or why
@@ -718,9 +718,10 @@ threads quietly block and unblock themselves.
 Larger increments or decrements are handy in those cases where a
 thread needs to check out or return a number of resources at once.
 
-=head2 cond_wait() and cond_signal()
+=head2 Waiting for a Condition
 
-These two functions can be used in conjunction with locks to notify
+The functions C<cond_wait()> and C<cond_signal()>
+can be used in conjunction with locks to notify
 co-operating threads that a resource has become available. They are
 very similar in use to the functions found in C<pthreads>. However
 for most purposes, queues are simpler to use and more intuitive. See
@@ -778,7 +779,7 @@ C<tid()> is a thread object method that returns the thread ID of the
 thread the object represents.  Thread IDs are integers, with the main
 thread in a program being 0.  Currently Perl assigns a unique TID to
 every thread ever created in your program, assigning the first thread
-to be created a tid of 1, and increasing the tid by 1 for each new
+to be created a TID of 1, and increasing the TID by 1 for each new
 thread that's created.  When used as a class method, C<threads-E<gt>tid()>
 can be used by a thread to get its own TID.
 
@@ -1020,7 +1021,9 @@ threads.  See L<threads/"THREAD SIGNALLING> for more details.)
 
 Whether various library calls are thread-safe is outside the control
 of Perl.  Calls often suffering from not being thread-safe include:
-C<localtime()>, C<gmtime()>, C<get{gr,host,net,proto,serv,pw}*()>, C<readdir()>,
+C<localtime()>, C<gmtime()>,  functions fetching user, group and
+network information (such as C<getgrent()>, C<gethostent()>,
+C<getnetent()> and so on), C<readdir()>,
 C<rand()>, and C<srand()> -- in general, calls that depend on some global
 external state.