Fix wording and spelling

Co-authored-by: Jagdish Prajapati <[email protected]>

Author: kahgoh

exercises/practice/bank-account/.approaches/introduction.md

@@ -13,8 +13,8 @@ If the threads happen to start simultaneously, they might both see the account s
 They each add $10 to this amount and update the account accordingly.
 In this case, each thread sets the amount to $10 even though the transaction was made twice.
 
-The problem here is both threads saw that was $0 in the account prior to adding the deposit.
-Instead, each thread needs to take turn to process the deposit for the account so that they can process the transaction one at a time.
+The problem here is that both threads saw that there was $0 in the account prior to adding the deposit.
+Instead, each thread needs to take turns to process the deposit for the account so that they can process the transaction one at a time.
 This way, the later thread can "see" the deposited amount from the first thread.
 
 ## Approach: Synchronized methods
@@ -342,10 +342,10 @@ For more information, check the [Read write lock approach][approach-read-write-l
 
 - The synchronized methods is the simplest, requiring no extra objects to be created.
 - Synchronized statements provide greater control over which code statements are performed with a lock and which object is to be used as the lock.
-- The read write lock allows greater concurrency by letting multiple read operations, such as `getBalance`, to run in parallel.
+- The read write lock allows greater concurrency by letting multiple read operations, such as `getBalance`, run in parallel.
   However, it requires the lock to be explicitly released.
 
-[approach-read-write-lock]: https://exercism.org/tracks/java/exercises/bank-account/approaches/read-write-lock
+[approach-read-write-lock]: https://exercism.org/tracks/java/exercises/bank-account/approaches/readwrite-lock
 [approach-reentrant-lock]: https://exercism.org/tracks/java/exercises/bank-acconuunt/approaches/reentrant-lock
 [approach-synchronized-methods]: https://exercism.org/tracks/java/exercises/bank-account/approaches/synchronized-methods
 [approach-synchronized-statements]: https://exercism.org/tracks/java/exercises/bank-account/approaches/synchronzied-statements

exercises/practice/bank-account/.approaches/readwrite-lock/content.md

@@ -85,10 +85,10 @@ class BankAccount {
 }
 ```
 
-A [ReadWriteLock][docs-readwritelock] provides two types of locks - one for reading the other for writing.
+A [ReadWriteLock][docs-readwritelock] provides two types of locks - one for reading, the other for writing.
 [ReentrantReadWriteLock][docs-reentrantreadwritelock] is an implementation of a [ReadWriteLock][docs-readwritelock].
 
-Read locks are intended for read only type operations, such as `getBalance`, and is acquired by calling `readLock().lock()` on the [ReadWriteLock][docs-readwritelock].
+Read locks are intended for read-only type operations, such as `getBalance`, and are acquired by calling `readLock().lock()` on the [ReadWriteLock][docs-readwritelock].
 Multiple threads are allowed to acquire read locks at the same time because they are expected to only read data.
 This means multiple threads can run `getBalance` at the same time.
 
@@ -99,7 +99,7 @@ Write locks are acquired by calling `writeLock().lock()` on the [ReadWriteLock][
 Only one thread can hold a write lock at a time.
 Therefore, `withdraw`, `deposit`, `open` and `close` can not run at the same time.
 Additionally, a thread must _also_ wait for _all_ read locks to be released to obtain a write lock.
-Similarly, threads must wait for write locks to be released before they granted a read lock.
+Similarly, threads must wait for write locks to be released before they are granted a read lock.
 This means `getBalance` also can not run at the same time as any of the `withdraw`, `deposit`, `open` and `close` methods.
 
 The locks are released in the `finally` block to ensure they are released, even when an exception is thrown.

exercises/practice/bank-account/.approaches/reentrant-lock/content.md

@@ -84,7 +84,7 @@ class BankAccount {
 ```
 
 A [ReentrantLock][docs-reentrantlock] object represents a lock that threads must acquire to perform certain operations.
-It used here by the operation methods to ensure they are not trying to update the bank account at the same time.
+It is used here by the operation methods to ensure they are not trying to update the bank account at the same time.
 
 The lock is requested by calling [lock][docs-reentrantlock-lock].
 The lock is released at the end of the operation by calling [unlock][docs-reentrantlock-unlock] in a `finally` block.