<meta name="GENERATOR" content="emacs and ten fingers" />
<title>Allocators and allocation</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
+<link rel="Start" href="../documentation.html" type="text/html"
+ title="GNU C++ Standard Library" />
+<link rel="Bookmark" href="howto.html" type="text/html"
+ title="General Utilities" />
<link rel="Copyright" href="../17_intro/license.html" type="text/html" />
</head>
<body>
</p>
<h3 class="left">
- <a name="standard requirements">Standard requirements</a>
+ <a name="standard_requirements">Standard requirements</a>
</h3>
<p>The C++ standard only gives a few directives in this area:
</p>
</p>
<h3 class="left">
- <a name="probs possibilities">Problems and Possibilities</a>
+ <a name="probs_possibilities">Problems and Possibilities</a>
</h3>
<p>The easiest way of fulfilling the requirements is to call operator new
each time a container needs memory, and to call operator delete each
</p>
<h3 class="left">
- <a name="ext allocators">Other allocators</a>
+ <a name="ext_allocators">Other allocators</a>
</h3>
<p> Several other allocators are provided as part of this
implementation. The location of the extension allocators and their
<h3 class="left">
- <a name="using custom allocators">Using a specific allocator</a>
+ <a name="using_custom_allocators">Using a specific allocator</a>
</h3>
<p>You can specify different memory management schemes on a
per-container basis, by overriding the default
<h3 class="left">
- <a name="custom allocators">Writing custom allocators</a>
+ <a name="custom_allocators">Writing custom allocators</a>
</h3>
<p> Writing a portable C++ allocator would dictate that the
interface would look much like the one specified for <code>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
- <meta name="AUTHOR" content="Stefan Olsson <stefan@xapa.se>" />
+ <meta name="AUTHOR" content="Stefan Olsson <stefan@xapa.se>" />
<meta name="KEYWORDS" content="c++, libstdc++, g++, allocator, memory" />
<meta name="DESCRIPTION" content="Allocators and allocation" />
<meta name="GENERATOR" content="emacs and ten fingers" />
<title>A fixed-size, multi-thread optimized allocator</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
+<link rel="Start" href="../documentation.html" type="text/html"
+ title="GNU C++ Standard Library" />
+<link rel="Bookmark" href="howto.html" type="text/html" title="Extensions" />
<link rel="Copyright" href="../17_intro/license.html" type="text/html" />
</head>
<body>
</p>
<pre>
- template<typename _Tp> size_t
- __mt_alloc<_Tp>::_S_freelist_headroom = 10;
+ template<typename _Tp> size_t
+ __mt_alloc<_Tp>::_S_freelist_headroom = 10;
</pre>
<p>
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).
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 ]
</p>
<p>
- 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.
</p>
<p>
- 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
| | |
+----------------+ |
+----------------+ |
-| next* |<-+ (If next == NULL it's the last one on the list)
+| next* |<-+ (If next == NULL it's the last one on the list)
| |
| |
| |
</p>
<p>
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.
</p>
<p>
If the requested size is within limits we start by finding out from which
<p>
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.
</p>
projects / platform / upstream / linaro-gcc.git / commitdiff