summaryrefslogtreecommitdiff
path: root/rts/STM.c
diff options
context:
space:
mode:
authorKirill Boltaev <johnathan.joestar@gmail.com>2013-11-01 19:13:39 +0400
committerKrzysztof Gogolewski <krz.gogolewski@gmail.com>2013-11-01 16:25:09 +0100
commitd943affc9121b91bc14e3798c6a2f1a5da38aef0 (patch)
tree4f982729134a903ce3306cc800ba4831774c219f /rts/STM.c
parenteaa4682b68348eb3b49a0bf2700abc58be820555 (diff)
downloadhaskell-d943affc9121b91bc14e3798c6a2f1a5da38aef0.tar.gz
Minor typos (fixes #8496)
Diffstat (limited to 'rts/STM.c')
-rw-r--r--rts/STM.c6
1 files changed, 3 insertions, 3 deletions
diff --git a/rts/STM.c b/rts/STM.c
index 8f4bdfbecb..e342ebf61e 100644
--- a/rts/STM.c
+++ b/rts/STM.c
@@ -7,7 +7,7 @@
* --------
*
* See the PPoPP 2005 paper "Composable memory transactions". In summary,
- * each transcation has a TRec (transaction record) holding entries for each of the
+ * each transaction has a TRec (transaction record) holding entries for each of the
* TVars (transactional variables) that it has accessed. Each entry records
* (a) the TVar, (b) the expected value seen in the TVar, (c) the new value that
* the transaction wants to write to the TVar, (d) during commit, the identity of
@@ -54,7 +54,7 @@
*
* lock_tvar / cond_lock_tvar and unlock_tvar are more complex because they
* have other effects (present in STM_UNIPROC and STM_CG_LOCK builds) as well
- * as the actual business of maniupultaing a lock (present only in STM_FG_LOCKS
+ * as the actual business of manipulating a lock (present only in STM_FG_LOCKS
* builds). This is because locking a TVar is implemented by writing the lock
* holder's TRec into the TVar's current_value field:
*
@@ -68,7 +68,7 @@
* unlock_tvar - release the lock on a specified TVar (STM_FG_LOCKS only),
* storing a specified value in place of the lock entry.
*
- * Using these operations, the typcial pattern of a commit/validate/wait operation
+ * Using these operations, the typical pattern of a commit/validate/wait operation
* is to (a) lock the STM, (b) lock all the TVars being updated, (c) check that
* the TVars that were only read from still contain their expected values,
* (d) release the locks on the TVars, writing updates to them in the case of a