[shmem] New snapshot available: Review Request
Hi to all! I've just uploaded a new snapshot of Shmem to Boost Vault/Memory folder. Online documentation, as always, is here: http://ice.prohosting.com/newfunk/boost/libs/shmem/doc/html/index.html New features: -> Windows API predeclaration so windows.h include is eliminated. Since Shmem is a header-only library, this change should help compile times. -> Null index type: If you don't need named allocations, and you want some space and compilation time, you can use a null index type instead of paying for an index you don't use. -> New synchronization primitive: named_mutex (Similar to Windows named mutex). -> Doxygen reference error corrections thanks a Boostbook Doxygen patch. There are some slight errors from BoostBook but now it looks much better. -> Improved named object destruction performance with destroy_ptr when using node container based indexes (map_index). Now is O(N) instead of O(logN). -> Decoupled red-black tree algorithms from shmem_tree class so that there is a good base for future shared memory intrusive rb_tree containers. -> Documentation corrections. Open issues, future work and references chapters added. -> Bugfixes. Tested in Windows XP with VC.NET 2003 and Suse 10.0 with gcc 4.0.2. I would like to request a review for Shmem to add it to Boost and I only plan to fix bugs until the review starts. I think there are some open issues in Shmem that should be solved (if Shmem is going to be accepted, of course) during the review. The most important ones are related to Boost Thread and the need of avoiding functionality duplication (scoped_locks, time representation, etc...). I've described them in Open Issues chapter of the documentation. If Shmem is considered good enough for Boost, I would like to work with Boost Thread's users and developers to have a common interface and utilities in thread-shared and process-shared synchronization objects, etc... I started Shmem 11 months ago (and the process of placing STL containers in shared memory many months before) and I would like to thank all who have tested the library, for all their ideas, suggestions and help. Regards, Ion
On 10/12/05, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
I think there are some open issues in Shmem that should be solved (if Shmem is going to be accepted, of course) during the review. The most important ones are related to Boost Thread and the need of avoiding functionality duplication (scoped_locks, time representation, etc...).
What about growing the shared memory region? Is that on the TODO list, or is it just too difficult to implement? -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein(e)k dio:
What about growing the shared memory region? Is that on the TODO list, or is it just too difficult to implement?
It's in the TO-DO list for the future. I have some ideas but this does not seem easy. If Shmem is accepted in Boost, growing shared memory would be the priority. Ion
On 10/12/05 12:33 PM, "Ion Gaztañaga" <igaztanaga@gmail.com> wrote:
I've just uploaded a new snapshot of Shmem to Boost Vault/Memory folder. Online documentation, as always, is here:
http://ice.prohosting.com/newfunk/boost/libs/shmem/doc/html/index.html
New features:
[SNIP]
-> Improved named object destruction performance with destroy_ptr when using node container based indexes (map_index). Now is O(N) instead of O(logN). [TRUNCATE]
Isn't O(N) worse than O(log N)? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker(e)k dio:
On 10/12/05 12:33 PM, "Ion Gaztañaga" <igaztanaga@gmail.com> wrote:
I've just uploaded a new snapshot of Shmem to Boost Vault/Memory folder. Online documentation, as always, is here:
http://ice.prohosting.com/newfunk/boost/libs/shmem/doc/html/index.html
New features:
[SNIP]
-> Improved named object destruction performance with destroy_ptr when using node container based indexes (map_index). Now is O(N) instead of O(logN).
[TRUNCATE]
Isn't O(N) worse than O(log N)?
Sorry! I meant constant O(1) time to find the node to erase from the index. When deallocating a named object constructed in shared memory, if the index is not a node based container (an ordered vector, for example) you must use the name to find the [name, pointer] entry and erase it from the index. If using a node container (a map, or hash_map) as index, an iterator of the named object is never invalidated if other objects are created, so it's stored in next to object. That way we can erase the index entry using erase(it) much faster than using erase(key). Thanks for pointing it out. Ion
participants (1)
-
Caleb Epstein -
Daryle Walker -
Ion Gaztañaga