[interprocess][Shared memory]
Please let me know, if there is any function in boost::interprocess, which can be used for cleanning up(filling up with particular value) the shared memory created. Like memset function in std::cstring. Regards, Shibu
On 3/5/07, Shibu Bera <shibu.ncst@gmail.com> wrote:
Please let me know, if there is any function in boost::interprocess, which can be used for cleanning up(filling up with particular value) the shared memory created. Like memset function in std::cstring.
This example shows memset being used: http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/interproc... http://tinyurl.com/ytdb7b Presumably std::fill or std::fill_n would work just as well. -- Caleb Epstein
Caleb Epstein wrote:
This example shows memset being used:
http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/interproc... http://tinyurl.com/ytdb7b
Thanks for the reply Caleb. Apart from that, shared memory is (or should be) guaranteed to be zero when it's created. Regards, Ion
Thanks a lot for the reply..... but, if shared memory is created with the class fixed_managed_shared_memory..? There is a method in the class get_address() which returns base address of the shared memory. Suppose if I memset this pointer, then initial mapping information kept inside the shared memory (map tree created by segment_manager and memory_algorithm) will also be lost. Please tell me any clue about this problem..? On 3/7/07, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Caleb Epstein wrote:
This example shows memset being used:
http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/interproc...
Thanks for the reply Caleb. Apart from that, shared memory is (or should be) guaranteed to be zero when it's created.
Regards,
Ion _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Regards, CBu..., Tata Power, Mumbai.......
Shibu Bera wrote:
Thanks a lot for the reply..... but, if shared memory is created with the class fixed_managed_shared_memory..? There is a method in the class get_address() which returns base address of the shared memory. Suppose if I memset this pointer, then initial mapping information kept inside the shared memory (map tree created by segment_manager and memory_algorithm) will also be lost. Please tell me any clue about this problem..?
Well, when fixed_managed_shared_memory is created, the memory is zeroed and after that, the map tree is created. Why do you want to memset all the segment to a particular value? I will need a bit more information of your needs. Regards, Ion
Hi, After creating the shared memory I put three containers (boost::multi_index, std::map and std::vector) into the shared memory, then objects into the containers. But in later part of the execution, there are condition when I need to remove these elements and containers. I also don't want to eat up the primary memory by creating the saparate shared memory nor I want to remove the earlier shared memory. If I just destroy the containers the previous garbage data may create problem. So I want such method or way to memset the shared memory with NULL characters. This information should suffice the query, Can I get some clue now? On 3/8/07, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Thanks a lot for the reply..... but, if shared memory is created with
Shibu Bera wrote: the
class fixed_managed_shared_memory..? There is a method in the class get_address() which returns base address of the shared memory. Suppose if I memset this pointer, then initial mapping information kept inside the shared memory (map tree created by segment_manager and memory_algorithm) will also be lost. Please tell me any clue about this problem..?
Well, when fixed_managed_shared_memory is created, the memory is zeroed and after that, the map tree is created. Why do you want to memset all the segment to a particular value? I will need a bit more information of your needs.
Regards,
Ion _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Regards, CBu..., Tata Power, Mumbai.......
Shibu Bera wrote:
Hi,
After creating the shared memory I put three containers (boost::multi_index, std::map and std::vector) into the shared memory, then objects into the containers. But in later part of the execution, there are condition when I need to remove these elements and containers. I also don't want to eat up the primary memory by creating the saparate shared memory nor I want to remove the earlier shared memory. If I just destroy the containers the previous garbage data may create problem. So I want such method or way to memset the shared memory with NULL characters. This information should suffice the query, Can I get some clue now?
Which type of problems, security problems? Or do you base your program on the value the memory you allocate has before using it? If your destroy the containers and after that you create new ones, I think you shouldn't have problems. If for any reason, (security or whatever) you need to guarantee that all free memory (memory that does not contain any object in the segment) is zeroed before being reused, I would need to add new functionality to the library, because this is not currently possible: the memory allocation algorithm should have a function that traverses all the free memory segments and memsets them. These days I will be busy with the Intrusive review, so you would need to wait until the end of the month to get this functionality. Regards, Ion
Hi, Thanks Lon for the nice reply. I hope I will get a new method very soon. I have one more query about the shared memory. I create shared memory using boost::interprocess, at linking time I add -lrt -lxml2 -lccext2 -lccgnu2 -ldl (common C++ link library) along with -Wall -pedantic -g -pthread -DBOOST_DATE_TIME_NO_LIB -DBOOST_INTERPROCESS_POSIX_PROCESS_SHARED -lstdc++ -lboost_thread (boost::interprocess link library). The common C++ library is added for the other requirement of the application. I open the shared memory form the another process, where "comman C++ link library" is not added. Segmentation fault is the result. Then I created two shared memory. First with "common C++ link library" and "boost::interprocess link library" And Second with only "boost::interprocess link library", These two shared memories are different, I found offset of some bytes on the actual values stored in the shared memory. I am not finding the way, why this problem is. I want to know how any other link libray may change the data of the shared memory. Please help. On 3/8/07, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Shibu Bera wrote:
Hi,
After creating the shared memory I put three containers (boost::multi_index, std::map and std::vector) into the shared memory, then objects into the containers. But in later part of the execution, there are condition when I need to remove these elements and containers. I also don't want to eat up the primary memory by creating the saparate shared memory nor I want to remove the earlier shared memory. If I just destroy the containers the previous garbage data may create problem. So I want such method or way to memset the shared memory with NULL characters. This information should suffice the query, Can I get some clue now?
Which type of problems, security problems? Or do you base your program on the value the memory you allocate has before using it? If your destroy the containers and after that you create new ones, I think you shouldn't have problems. If for any reason, (security or whatever) you need to guarantee that all free memory (memory that does not contain any object in the segment) is zeroed before being reused, I would need to add new functionality to the library, because this is not currently possible: the memory allocation algorithm should have a function that traverses all the free memory segments and memsets them.
These days I will be busy with the Intrusive review, so you would need to wait until the end of the month to get this functionality.
Regards,
Ion _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Regards, CBu..., Tata Power, Mumbai.......
Hi, Is it possible to use boost interprocess' shared memory allocator with the normal STL containers that come with standard C++ build environments (gcc on Linux and Solaris, Visual C++ on Windows, etc.)? I know that there might be an issue with some STL containers not properly supporting encapsulated pointers that handle offset differences in memory addresses. Is this the reason why interprocess has its own containers? I apologize if this is a fairly basic question. But I think I may have hit a search blind-spot, and need some help getting out. Thanks in advance. Regards, Vishnu. ____________________________________________________________________________________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121
Shibu Bera wrote:
Hi,
Thanks Lon for the nice reply. I hope I will get a new method very soon.
I have one more query about the shared memory.
I create shared memory using boost::interprocess, at linking time I add
-lrt -lxml2 -lccext2 -lccgnu2 -ldl (common C++ link library) along with
-Wall -pedantic -g -pthread -DBOOST_DATE_TIME_NO_LIB -DBOOST_INTERPROCESS_POSIX_PROCESS_SHARED -lstdc++ -lboost_thread (boost::interprocess link library).
Why do you define BOOST_INTERPROCESS_POSIX_PROCESS_SHARED? This is an internal define that will be generated if Interprocess can detect POSIX process-shared mutexes. Otherwise, if you are using gcc, atomic operations would be used. Which system are you using, Linux?
The common C++ library is added for the other requirement of the application.
I open the shared memory form the another process, where "comman C++ link library" is not added. Segmentation fault is the result.
Then I created two shared memory. First with "common C++ link library" and "boost::interprocess link library" And Second with only "boost::interprocess link library",
These two shared memories are different, I found offset of some bytes on the actual values stored in the shared memory. I am not finding the way, why this problem is. I want to know how any other link libray may change the data of the shared memory. Please help.
Sorry, I can't understand your problem properly. Linking another library is not important to use Interprocess. Can you elaborate a bit more? Please remove the define I mentioned before, because otherwise you might have problems. Regards, Ion
yes u r right. Linking another library is not important to use interprocess. But because there is requirment of the other part of the application I am including the link library of comman c++ while creating executable , If I woudn't link comman c++, still shared memory would have beed created. But including comman c++ link library, the shared memory is created is different from the shared memory which is created without comman c++ link library. And in the shared memory I am finding offset of some bytes on the actual value stored in the shared memory. On 3/9/07, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Shibu Bera wrote:
Hi,
Thanks Lon for the nice reply. I hope I will get a new method very soon.
I have one more query about the shared memory.
I create shared memory using boost::interprocess, at linking time I add
-lrt -lxml2 -lccext2 -lccgnu2 -ldl (common C++ link library) along with
-Wall -pedantic -g -pthread -DBOOST_DATE_TIME_NO_LIB -DBOOST_INTERPROCESS_POSIX_PROCESS_SHARED -lstdc++ -lboost_thread (boost::interprocess link library).
Why do you define BOOST_INTERPROCESS_POSIX_PROCESS_SHARED? This is an internal define that will be generated if Interprocess can detect POSIX process-shared mutexes. Otherwise, if you are using gcc, atomic operations would be used. Which system are you using, Linux?
The common C++ library is added for the other requirement of the application.
I open the shared memory form the another process, where "comman C++ link library" is not added. Segmentation fault is the result.
Then I created two shared memory. First with "common C++ link library" and "boost::interprocess link library" And Second with only "boost::interprocess link library",
These two shared memories are different, I found offset of some bytes on the actual values stored in the shared memory. I am not finding the way, why this problem is. I want to know how any other link libray may change the data of the shared memory. Please help.
Sorry, I can't understand your problem properly. Linking another library is not important to use Interprocess. Can you elaborate a bit more? Please remove the define I mentioned before, because otherwise you might have problems.
Regards,
Ion
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Regards, CBu..., Tata Power, Mumbai.......
Shibu Bera wrote:
yes u r right. Linking another library is not important to use interprocess. But because there is requirment of the other part of the application I am including the link library of comman c++ while creating executable , If I woudn't link comman c++, still shared memory would have beed created.
But including comman c++ link library, the shared memory is created is different from the shared memory which is created without comman c++ link library. And in the shared memory I am finding offset of some bytes on the actual value stored in the shared memory.
Please post the two complete command lines. You may first try to add -lrt to the program that doesn't use the "common C++ library". Also, remove the -DBOOST_INTERPROCESS_POSIX_PROCESS_SHARED as Ion stated.
Thanks for the reply. I am sending the code and other details please view. O/S :: linux fedora filename : main.cpp #include <boost/interprocess/allocators/allocator.hpp> #include <boost/interprocess/detail/config_begin.hpp> #include <boost/interprocess/detail/workaround.hpp> #include <boost/interprocess/managed_shared_memory.hpp> int main() { boost::interprocess::fixed_managed_shared_memory segment ( boost::interprocess::open_or_create, "MySharedMemory", //segment name 1024 * 1024 ); return 0; } command # g++ -c main.cpp command # g++ g++ -o exec main.o -Wall -pedantic -g -pthread -DBOOST_DATE_TIME_NO_LIB -lstdc++ -lboost_thread /*linking without comman c++ */ command # ./exec command # cp /dev/shm/MySharedMemory shm_without_ccpp /* copy of shared memoty created */ command # rm /dev/shm/MySharedMemory /* remove created shared memoty using comman line */ command # g++ -o exec main.o -Wall -pedantic -g -pthread -DBOOST_DATE_TIME_NO_LIB -lstdc++ -lboost_thread -lxml2 -lccext2 -lccgnu2 -ldl /* linking with comman c ++ */ command # ./exec command # cp /dev/shm/MySharedMemory shm_with_ccpp /* copy of shared memory created */ command # diff shm_without_ccpp shm_with_ccpp Binary files shm_without_ccpp and shm_with_ccpp differ Here I am comparing the two shared memories created. It says these are different. I am not getting just adding a library in link time, how shared memory is changed. Can I get some clue now? On 3/9/07, Peter Dimov <pdimov@mmltd.net> wrote:
Shibu Bera wrote:
yes u r right. Linking another library is not important to use interprocess. But because there is requirment of the other part of the application I am including the link library of comman c++ while creating executable , If I woudn't link comman c++, still shared memory would have beed created.
But including comman c++ link library, the shared memory is created is different from the shared memory which is created without comman c++ link library. And in the shared memory I am finding offset of some bytes on the actual value stored in the shared memory.
Please post the two complete command lines.
You may first try to add -lrt to the program that doesn't use the "common C++ library".
Also, remove the -DBOOST_INTERPROCESS_POSIX_PROCESS_SHARED as Ion stated.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Regards, CBu..., Tata Power, Mumbai.......
Shibu Bera wrote:
int main() { boost::interprocess::fixed_managed_shared_memory segment ( boost::interprocess::open_or_create, "MySharedMemory", //segment name 1024 * 1024 ); return 0; }
If you are using a fixed address shared memory, you should specify the mapping address, otherwise, you can get a different one each execution. After all, this is what fixed mapping is about ;-) I think I should force the use of an address in this class (currently fixed_managed_shared_memory segment is a typedef of basic_managed_shared_memory segment so by default and an address is not requested). Please, try the same specifying an address (add another parameter to the constructor). The address depends on the OS you are using. Try, for example (void*)0x30000000. Or just use managed_shared_memory segment. Why do you need fixed address mappings? Regards, Ion
participants (5)
-
Caleb Epstein -
Ion Gaztañaga -
Peter Dimov -
Shibu Bera -
Vishnu M Menon