- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am using intel compiler for OpenMP parallel processing support in VC++ 6.0. One component which uses OpenMP for parallel processing is loaded at runtime by using LoadLibrary call. After use, it will be unloaded. My problem is that every time when I use this component, new threads are getting created. Old threads created in previous runs are still in memory.
So the threadstack is consuming a large amount of memory.
Is there any way to close threads created by omp_set_num_threads.
I am using intel compiler for OpenMP parallel processing support in VC++ 6.0. One component which uses OpenMP for parallel processing is loaded at runtime by using LoadLibrary call. After use, it will be unloaded. My problem is that every time when I use this component, new threads are getting created. Old threads created in previous runs are still in memory.
So the threadstack is consuming a large amount of memory.
Is there any way to close threads created by omp_set_num_threads.
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you structure your application to leave the library open?
Jim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - jimdempseyatthecove
Can you structure your application to leave the library open?
Jim
Thanks Jim..
It worked fine after I made the library to stay in memory even after use. But I would like to know if there is any way to cleanup the thread/threadpool cretaed during runtime after its use.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I do not think there is a formal (clean) way to do this.
You could:
a) make note of the handles for threads you create independent of OpenMP
b) ASSUME all other threads are cancelable
c) terminate threads not in your list of your managed threads
As to if this will crash your application now, or later, is purely speculative.
The cost of keeping the library and threads in memory are some portion of your virtual memory is consumed and some system resources. When on x64 platform this should not be of concern. On x32 this may be of concern when your application is tight on space/resources.
Because your initial design was to
load the OpenMP runtime library
launch OpenMP parallel regions
consolidate back to the "main" thread that launched the OpenMP parallel regions
terminate the OpenMP threads (somehow)
unload the OpenMP runtime library
Then periodically do the above again and again in your application
I can only guess that the memory footprint concerns is more important than the runtime overhead in starting and stopping the OpenMP environment. This may be a legitimate concern.
As a work around (assuming you must reclaim the memory)
Encapsulate you parallel code into an application (execuitable).
From the original app then launch the encapsulated parallel code as a seperate process.
Then have the original app and parallel app use memory mapped files to map common data.
When you wish to exit the OpenMP code, your application simply terminates (taking all its OpenMP threads with it).
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I forgot to mention that on x32 the seperate process with memory mapped file permits you to effectively overlap two 2GB applicaions. e.g. with 500MB mapped total memory is 3.5GB.
Jim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - jimdempseyatthecove
I forgot to mention that on x32 the seperate process with memory mapped file permits you to effectively overlap two 2GB applicaions. e.g. with 500MB mapped total memory is 3.5GB.
Jim
Currently I will stick to keeping DLL loaded in memory after use.
Thanks Jim for detailed reply.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page