OpenCascade/occt
1
0
Fork 0
mirror of https://git.dev.opencascade.org/repos/occt.git synced 2025-04-04 18:06:22 +03:00
Code Packages Releases Activity

0025072: Environment variable MMGT_REENTRANT is still mentioned in the Overview although it was removed

Browse Source 
References to MMGT_REENTRANT are removed from docs
This commit is contained in:
abv 2014-09-26 14:20:06 +04:00 committed by bugmaster
parent c1e18dd843
commit 7277133aa9
2 changed files with 4 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
dox/overview/overview.md
View File

@ -399,7 +399,7 @@ The scripts are located in the OCCT root folder.
* **MMGT_OPT** (optional) if set to 1, the memory manager performs optimizations as described below; if set to 2,
Intel (R) TBB optimized memory manager is used; if 0 (default), every memory block is allocated
in C memory heap directly (via malloc() and free() functions).
In the latter case, all other options except MMGT_CLEAR and MMGT_REENTRANT are ignored;
In the latter case, all other options except MMGT_CLEAR are ignored;
* **MMGT_CLEAR** (optional) if set to 1 (default), every allocated memory block is cleared by zeros;
if set to 0, memory block is returned as it is;
* **MMGT_CELLSIZE** (optional) defines the maximal size of blocks allocated in large pools of memory. Default is 200;

8
dox/user_guides/foundation_classes/foundation_classes.md
View File

@ -534,10 +534,7 @@ The configuration is defined by numeric values of the following environment var
* *MMGT_NBPAGES*: defines the size of memory chunks allocated for small blocks in pages (operating-system dependent). Default is 1000.
* *MMGT_THRESHOLD*: defines the maximal size of blocks that are recycled internally instead of being returned to the heap. Default is 40000.
* *MMGT_MMAP*: when set to 1 (default), large memory blocks are allocated using memory mapping functions of the operating system; if set to 0, they will be allocated in the C heap by *malloc()*.
* *MMGT_REENTRANT*: when set to 1 (default), all calls to the optimized memory manager will be secured against possible simultaneous access from different execution threads. This variable should be set in any multithreaded application that uses an optimized memory manager (*MMGT_OPT=1*) and has more than one thread potentially calling OCCT functions. If set to 0, OCCT memory management and exception handling routines will skip the code protecting from possible concurrency in multi-threaded environment. This can yield some performance gain in some applications, but can lead to unpredictable results if used in a multithreaded application.
**Note** it is recommended to use options *MMGT_OPT=2* and *MMGT_REENTRANT=1* for applications that use OCCT memory manager from more than one thread, on multiprocessor hardware.
@subsubsection occt_fcug_2_3_3 Implementation details
When *MMGT_OPT* is set to 1, the following optimization techniques are used:
* Small blocks with a size less than *MMGT_CELLSIZE*, are not allocated separately. Instead, a large pools of memory are allocated (the size of each pool is *MMGT_NBPAGES* pages). Every new memory block is arranged in a spare place of the current pool. When the current memory pool is completely occupied, the next one is allocated, and so on.
@ -564,7 +561,8 @@ Note that these overheads may be greater or less than overheads induced by the
As a general rule, it is advisable to allocate memory through significant blocks. In this way, you can work with blocks of contiguous data, and processing is facilitated for the memory page manager.
In multithreaded mode <i>(MMGT_REENTRANT=1)</i>, the OCCT memory manager uses mutex to lock access to free lists, therefore it may have less performance than non-optimized mode in situations when different threads often make simultaneous calls to the memory manager. The reason is that modern implementations of *malloc()* and *free()* employ several allocation arenas and thus avoid delays waiting mutex release, which are possible in such situations.
OCCT memory manager uses mutex to lock access to free lists, therefore it may have less performance than non-optimized mode in situations when different threads often make simultaneous calls to the memory manager.
The reason is that modern implementations of *malloc()* and *free()* employ several allocation arenas and thus avoid delays waiting mutex release, which are possible in such situations.
@subsection occt_fcug_2_4 Exception Handling
Exception handling provides a means of transferring control from a given point in a program being executed to an **exception handler** associated with another point previously executed.