From f3fdfc90907ca0a29d5cc906de68fd19bc2b0cbc Mon Sep 17 00:00:00 2001 From: ivmai Date: Thu, 29 Apr 2010 10:31:52 +0000 Subject: [PATCH] 2010-04-29 Ivan Maidanski * doc/README_malloc.txt: Fix a typo. * doc/README_stack.txt: Ditto. --- ChangeLog | 5 +++++ doc/README_malloc.txt | 4 ++-- doc/README_stack.txt | 2 +- 3 files changed, 8 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5756153..a1bb929 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2010-04-29 Ivan Maidanski + + * doc/README_malloc.txt: Fix a typo. + * doc/README_stack.txt: Ditto. + 2010-02-25 Ivan Maidanski (really Bruce Mitchener) * .cvsignore: New file. diff --git a/doc/README_malloc.txt b/doc/README_malloc.txt index 680b3e2..ec4ed89 100644 --- 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 98ff87c..52edbb5 100644 --- 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: -- 2.40.0