Some typo fixes

doc/Type/Lock.pod6

@@ -23,14 +23,14 @@ of state. For example, in this program:
     say $x;         # OUTPUT: «10␤»
 
 The C<Lock> is used to protect operations on C<$x>. An increment is
-not an atomic opreation; without the lock, it would be possible for
+not an atomic operation; without the lock, it would be possible for
 two threads to both read the number 5 and then both store back the
 number 6, thus losing an update. With the use of the C<Lock>, only
 one thread may be running the increment at a time.
 
 A C<Lock> is re-entrant, meaning that a thread that holds the lock can
 lock it again without blocking. That thread must unlock the same number
-of times before the lock can be obtaiend by another thread (it works by
+of times before the lock can be obtained by another thread (it works by
 keeping a recursion count).
 
 It's important to understand that there is no direct connection between

doc/Type/Lock/Async.pod6

@@ -20,7 +20,7 @@ and the code trying to obtain the lock will be resumed once it is available.
 
 The result is that it's quite possible to have many thousands of outstanding
 C<Lock::Async> lock requests, but just a small number of threads in the
-pool. Attemtping that with a traditional L<Lock|/type/Lock> would not go so
+pool. Attempting that with a traditional L<Lock|/type/Lock> would not go so
 well!
 
 There is no requirement that a C<Lock::Async> is locked and unlocked by the
@@ -113,7 +113,7 @@ wants to obtain the lock, but not to execute that code).
     $l.unlock;
 
 Prefer to use L<protect|/type/Lock/Async#method_protect> instead of
-explicit calls to C<lock> and C<unlock>. However, it wishing to use
+explicit calls to C<lock> and C<unlock>. However, if wishing to use
 the methods separately, it is wise to use a C<LEAVE> block to ensure
 that C<unlock> is reliably called. Failing to C<unlock> will mean that
 nobody can ever C<lock> this particular C<Lock::Async> instance again.