From cec0e70b442f27e1eab654061caf454de8e1ea5e Mon Sep 17 00:00:00 2001 From: Jonathan Wakely Date: Thu, 26 Feb 2004 11:35:06 +0000 Subject: [PATCH] howto.html, [...]: Fix markup, more tags. 2004-02-25 Jonathan Wakely * docs/html/20_util/howto.html, docs/html/20_util/allocator.html, docs/html/ext/howto.html, docs/html/ext/mt_allocator.html: Fix markup, more tags. From-SVN: r78495 --- libstdc++-v3/ChangeLog | 6 +++++ libstdc++-v3/docs/html/20_util/allocator.html | 14 +++++++---- libstdc++-v3/docs/html/20_util/howto.html | 2 ++ libstdc++-v3/docs/html/ext/howto.html | 2 ++ libstdc++-v3/docs/html/ext/mt_allocator.html | 25 +++++++++++-------- 5 files changed, 33 insertions(+), 16 deletions(-) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index 2c1683878d3..a09a97d4aee 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,9 @@ +2004-02-25 Jonathan Wakely + + * docs/html/20_util/howto.html, docs/html/20_util/allocator.html, + docs/html/ext/howto.html, docs/html/ext/mt_allocator.html: + Fix markup, more tags. + 2004-02-25 Carlo Wood * bits/demangle.h diff --git a/libstdc++-v3/docs/html/20_util/allocator.html b/libstdc++-v3/docs/html/20_util/allocator.html index 43aaae7e079..07e8e2dd909 100644 --- a/libstdc++-v3/docs/html/20_util/allocator.html +++ b/libstdc++-v3/docs/html/20_util/allocator.html @@ -11,6 +11,10 @@ Allocators and allocation + + @@ -35,7 +39,7 @@

- Standard requirements + Standard requirements

The C++ standard only gives a few directives in this area:

@@ -74,7 +78,7 @@

- Problems and Possibilities + Problems and Possibilities

The easiest way of fulfilling the requirements is to call operator new each time a container needs memory, and to call operator delete each @@ -256,7 +260,7 @@

- Other allocators + Other allocators

Several other allocators are provided as part of this implementation. The location of the extension allocators and their @@ -381,7 +385,7 @@

- Using a specific allocator + Using a specific allocator

You can specify different memory management schemes on a per-container basis, by overriding the default @@ -397,7 +401,7 @@

- Writing custom allocators + Writing custom allocators

Writing a portable C++ allocator would dictate that the interface would look much like the one specified for diff --git a/libstdc++-v3/docs/html/20_util/howto.html b/libstdc++-v3/docs/html/20_util/howto.html index 9597707a8be..4c404595a47 100644 --- a/libstdc++-v3/docs/html/20_util/howto.html +++ b/libstdc++-v3/docs/html/20_util/howto.html @@ -18,6 +18,8 @@ title="Diagnostics" /> + diff --git a/libstdc++-v3/docs/html/ext/howto.html b/libstdc++-v3/docs/html/ext/howto.html index 3e5c35c476c..41fe10b1548 100644 --- a/libstdc++-v3/docs/html/ext/howto.html +++ b/libstdc++-v3/docs/html/ext/howto.html @@ -18,6 +18,8 @@ title="Input/Output" /> + diff --git a/libstdc++-v3/docs/html/ext/mt_allocator.html b/libstdc++-v3/docs/html/ext/mt_allocator.html index e806395d9ad..72727114ac6 100644 --- a/libstdc++-v3/docs/html/ext/mt_allocator.html +++ b/libstdc++-v3/docs/html/ext/mt_allocator.html @@ -5,12 +5,15 @@ - + A fixed-size, multi-thread optimized allocator + + @@ -61,8 +64,8 @@ are initialized to their default values at file scope, i.e.: 

-  template size_t
-  __mt_alloc<_Tp>::_S_freelist_headroom = 10;
+  template<typename _Tp> size_t
+  __mt_alloc<_Tp>::_S_freelist_headroom = 10;

@@ -100,7 +103,7 @@ The _S_init() function: as many bin_records in this array as the number of bins that we calculated earlier. I.e., if _S_max_bytes = 128 there will be 8 entries. Each bin_record is then initialized: - - bin_record->first = An array of pointers to block_records. There will be + - bin_record->first = An array of pointers to block_records. There will be as many block_records pointers as there are maximum number of threads (in a ST application there is only 1 thread, in a MT application there are _S_max_threads). @@ -127,7 +130,7 @@ The _S_init() function: created thread and we pop the first entry from this list and saves the pointer to this record in the _S_thread_key variable. The next time we will get the pointer to the thread_record back and we use the - thread_record->thread_id as identification. I.e., the first thread that + thread_record->thread_id as identification. I.e., the first thread that calls allocate will get the first record in this list and thus be thread number 1 and will then find the pointer to its first free 32 byte block in _S_bin[ 5 ].first[ 1 ] @@ -140,12 +143,12 @@ The _S_init() function:

- Initialize the free and used counters of each bin_record: - - bin_record->free = An array of size_t. This keeps track of the number + - bin_record->free = An array of size_t. This keeps track of the number of blocks on a specific thread's freelist in each bin. I.e., if a thread has 12 32-byte blocks on it's freelists and allocates one of these, this counter would be decreased to 11. - - bin_record->used = An array of size_t. This keeps track of the number + - bin_record->used = An array of size_t. This keeps track of the number of blocks currently in use of this size by this thread. I.e., if a thread has made 678 requests (and no deallocations...) of 32-byte blocks this counter will read 678. @@ -155,7 +158,7 @@ The _S_init() function:

- Initialize the mutex of each bin_record: - The bin_record->mutex is used to protect the global freelist. This concept + The bin_record->mutex is used to protect the global freelist. This concept of a global freelist is explained in more detail in the section "A multi threaded example", but basically this mutex is locked whenever a block of memory is retrieved or returned to the global freelist for this @@ -194,7 +197,7 @@ This is the first two blocks in freelist for thread id 3 in bin 3 (8 bytes): | | | +----------------+ | +----------------+ | -| next* |<-+ (If next == NULL it's the last one on the list) +| next* |<-+ (If next == NULL it's the last one on the list) | | | | | | @@ -223,7 +226,7 @@ assigned this id since they span from 1 to _S_max_threads in a MT application).

When the application requests memory (calling allocate()) we first look at the -requested size and if this is > _S_max_bytes we call new() directly and return. +requested size and if this is > _S_max_bytes we call new() directly and return.

If the requested size is within limits we start by finding out from which @@ -297,7 +300,7 @@ not when a deallocation occurs.

When the application requests memory (calling allocate()) we first -look at the requested size and if this is > _S_max_bytes we call new() +look at the requested size and if this is > _S_max_bytes we call new() directly and return.