2010-04-29 Ivan Maidanski <ivmai@mail.ru>

	* doc/README_malloc.txt: Fix a typo.
	* doc/README_stack.txt: Ditto.

diff --git a/ChangeLog b/ChangeLog
index 57561537b7d988e7f8225717347ffc5b440bf3ce..a1bb929c94f933a2364e3d770d25663a49ba4312 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2010-04-29  Ivan Maidanski <ivmai@mail.ru>
+
+       * doc/README_malloc.txt: Fix a typo.
+       * doc/README_stack.txt: Ditto.
+
 2010-02-25  Ivan Maidanski <ivmai@mail.ru> (really Bruce Mitchener)
 
        * .cvsignore: New file.

diff --git a/doc/README_malloc.txt b/doc/README_malloc.txt
index 680b3e242225789bce56de32737f79837343d882..ec4ed891e2006b39b371bdd422aa1419571e1636 100644 (file)
--- a/doc/README_malloc.txt
+++ b/doc/README_malloc.txt
@@ -23,7 +23,7 @@ quite poor in practice.  In particular, no attempt is made to
 coalesce free small memory blocks.  Something like Doug Lea's malloc is
 likely to use significantly less memory for complex applications.
 
-Perfomance on platforms without an efficient compare-and-swap implementation
+Performance on platforms without an efficient compare-and-swap implementation
 will be poor.
 
 This package was not designed for processor-scalability in the face of
@@ -31,7 +31,7 @@ high allocation rates.  If all threads happen to allocate different-sized
 objects, you might get lucky.  Otherwise expect contention and false-sharing
 problems.  If this is an issue, something like Maged Michael's algorithm
 (PLDI 2004) would be technically a far better choice.  If you are concerned
-only with scalablity, and not signal-safety, you might also consider
+only with scalability, and not signal-safety, you might also consider
 using Hoard instead.  We have seen a factor of 3 to 4 slowdown from the
 standard glibc malloc implementation with contention, even when the
 performance without contention was faster.  (To make the implementation

diff --git a/doc/README_stack.txt b/doc/README_stack.txt
index 98ff87ccb6d0f0937952a967bcd003e32882a5e7..52edbb5ac76287b1d80769c1710d1d584164e709 100644 (file)
--- a/doc/README_stack.txt
+++ b/doc/README_stack.txt
@@ -12,7 +12,7 @@ seems to rarely be useful, especially since larger N involve some slowdown.)
 This makes it safe to access these data structures from non-reentrant
 signal handlers, provided at most one non-signal-handler thread is
 accessing the data structure at once.  This latter condition can be
-ensured by acquiring an ordinary lock around the non-hndler accesses
+ensured by acquiring an ordinary lock around the non-handler accesses
 to the data structure.
 
 For details see: