Re: [Boost-users] [interprocess] shared_memory_object constructor with create_only parameter
Hi all, I am sorry. I made a mistake. My first problem is solved. It is not a bug.
I have some problems using the shared_memory_object constructor with the create_only parameter. The goal is to allow only one process to write to the shared memory. So I create a shared_memory_object with the create_only parameter. For the first process this is successful (as I assumed), but for the second process (same parameters) this is successful, too (not as I assumed). The documentation of boost says that it should throw an exception, if the shared memory is allready created. Is this a bug or a misuse or understanding of the library?
But the second problem concerning shared_memory_object::remove(const char* name) is still present.
I realized another problem. If I call the static function shared_memory_object::remove(const char* name), the memory should be removed only when no further process has access to the memory. This seems also not to work. I did the following: 1. create shared memory for writing. 2. open shared memory for reading 3. shared_memory_object::remove(const char* name) (from the reading process) 4. reopen the shared memory for reading -> exception: can not find the file
Thanks for your help and apoligizes for bothering you with my first problem. Philipp
But the second problem concerning shared_memory_object::remove(const char* name) is still present.
I realized another problem. If I call the static function shared_memory_object::remove(const char* name), the memory should be removed only when no further process has access to the memory. This seems also not to work. I did the following: 1. create shared memory for writing. 2. open shared memory for reading 3. shared_memory_object::remove(const char* name) (from the reading process) 4. reopen the shared memory for reading -> exception: can not find the file
Thanks for your help and apoligizes for bothering you with my first problem.
Philipp
Hi Philipp, Check out http://www.boost.org/doc/libs/1_41_0/doc/html/interprocess/sharedmemorybetwe... If you call remove on a shared memory object, you are unable to reopen a shared memory object with that name. Hope that helps. Derek Kivi ver. QuIC 0707
Thanks Derek, I should have read the manual more carefully. But nevertheless this behaviour is strange. When one process closes the shared memory, it can not be reopened by another one? Thus the processes are not independent any more. Is there a best practice, how to handle this? I have only one writing process, but several readers. So I call shared_memory_object::remove only when the writer is destroyed. But I have to take care, that the readers are destroyed before the writer is destroyed, otherwise the memory is not freed. But what to do if I have several writers, which could open and close the shared mem, whenever they like to? How do you handle this?
Thanks Derek, I should have read the manual more carefully.
But nevertheless this behaviour is strange. When one process closes the shared memory, it can not be reopened by another one? Thus the processes are not independent any more.
Is there a best practice, how to handle this? I have only one writing process, but several readers. So I call shared_memory_object::remove only when the writer is destroyed. But I have to take care, that the readers are destroyed before the writer is destroyed, otherwise the memory is not freed.
But what to do if I have several writers, which could open and close the shared mem, whenever they like to?
How do you handle this?
Hi Philipp, We had this same question as well. We solved it by keeping an integer reference counter inside the shared memory. We incremented it whenever we created or opened a shared memory object with a given name, and decremented it before deleting a shared memory object with that name. Only when the count was zero would we actually call shared_memory_object::remove to remove that shared memory from the system. Derek Kivi ver. QuIC 0707
Thanks for your help Derek. Now I understand the use of the shared_mem_object much better. And I know that there is some strange behaviour, but that you can handle this. Philipp
participants (2)
-
Derek Kivi -
Philipp Hamann