[shmem] Some proposals for open issues from the review
Hi to all, After Shmem review, I've been re-reading some review comments and there were some issues not completely solved during the review: * Library name: Some don't like the Shmem name for the library and since the library offers also a process shared message queue and memory mapped files and surely we will have more interprocess mechanisms in the future (pipes, for example), I'm proposing the Boost.IPC or Boost.InterProcess name (boost::ipc or boost::interprocess namespace). I don't know if it's even worse or if it expresses better the purpose of the library. Just an idea. * Class names: I propose changing "mmaped_file" class to simply "mapped_file", so we have "mapped_file" and "mapped_region" classes. The classes that I call "front-ends" (a name that some don't like and if someone has a better I would be glad to use it) have the following names: ->named_shared_object (the class that allows named object construction in shared memory) ->named_mfile_object (the class that allows named object construction in memory mapped files) ->named_heap_object (the class that allows named object construction in a heap memory buffer) ->named_user_object (the class that allows named object construction in an user provided buffer) I don't like much those names but I couldn't find better alternatives. In response to Kim Barrett's review I proposed the following: ->shared_memory_xxx ->mapped_file_xxx ->heap_memory_xxx ->external_memory_xxx where xxx can be something like "services", "framework", "objects", or we can add a "smart" prefix to those names. I would like to receive suggestions for better names. I think it's important to choose better names before the library is released. * Changes from Boost.Thread interface: Now that Boost.Date_Time has been chosen as time representation for timed functions of the synchronization primitives, I would also propose a simplification of synchronization primitives. Currently, following Boost.Thread interface, mutex lock and unlock functions are private, but I would prefer making them public, and implement a unique scoped lock class that can lock any "lockable" object (shared_mutex, shared_recursive_mutex, named_mutex). This general locker could be moved to boost utilities or be just for this library. Or do you consider "too dangerous" to have lock functions public?. This is a proposal based on Howard Hinnant's much more complete scoped_lock proposal (http://home.twcny.rr.com/hinnant/cpp_extensions/threads_move.html): namespace boost { namespace shmem/ipc/interprocess { template <class Mutex> class scoped_lock { public: typedef Mutex mutex_type; explicit scoped_lock(mutex_type& m); scoped_lock(mutex_type& m, detail::dont_lock_type); scoped_lock(mutex_type& m, detail::try_lock_type); scoped_lock(mutex_type& m, const boost::posix_time::ptime &time); private: scoped_lock(scoped_lock const&); scoped_lock& operator= (scoped_lock const&); public: ~scoped_lock(); public: void lock(); bool try_lock(); bool timed_lock(const boost::posix_time::ptime &time); void unlock(); bool locked() const; operator unspecified_bool_type () const; mutex_type* mutex() const; private: mutex_type& m_mut; bool m_locked; }; }} This locker can be used would be usable with any class that has required lock()/unlock/try_lock()/timed_lock() functions. The mutex doesn't need try_lock/timed_lock functions if we don't use scoped_lock's try_lock/timed_lock functions. Since the class is a template, try_lock()/timed_lock() won't be instantiated. I also think that there too many mutex types: -> shared_mutex -> shared_try_mutex -> shared_timed_mutex -> shared_recursive_mutex -> shared_recursive_try_mutex -> shared_recursive_timed_mutex -> named_mutex I think that all can be condensed in shared_mutex, shared_recursive_mutex and named_mutex types without overhead, since Windows and POSIX systems offer try/timed functions for mutexes. So we can pass from 7 mutex types to 3 and from 3 lockers to just 1. To sum up proposals regarding this point: -> Public lock/unlock functions? -> Merging 7 mutex types into 3? -> Merging 3 scoped_lock types into 1? Regards, Ion
Ion Gaztañaga wrote: [...]
for example), I'm proposing the Boost.IPC or Boost.InterProcess name (boost::ipc or boost::interprocess namespace).
I like IPC.
-> Public lock/unlock functions? -> Merging 7 mutex types into 3? -> Merging 3 scoped_lock types into 1?
Yes to all.
Peter Dimov wrote:
Ion Gaztañaga wrote:
[...]
for example), I'm proposing the Boost.IPC or Boost.InterProcess name (boost::ipc or boost::interprocess namespace).
I like IPC.
I don't like IPC, because the library is not just for communications. "InterProcess" seems like the most descriptive. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Peter Dimov wrote:
Ion Gaztañaga wrote:
[...]
for example), I'm proposing the Boost.IPC or Boost.InterProcess name (boost::ipc or boost::interprocess namespace).
I like IPC.
I don't like IPC, because the library is not just for communications. "InterProcess" seems like the most descriptive.
Isn't sharing memory all about communication ? Regards, Stefan
Rene Rivera wrote:
Peter Dimov wrote:
Ion Gaztañaga wrote:
[...]
for example), I'm proposing the Boost.IPC or Boost.InterProcess name (boost::ipc or boost::interprocess namespace).
I like IPC.
I don't like IPC, because the library is not just for communications. "InterProcess" seems like the most descriptive.
IPC > InterProcess, even for a library that is not just for communications. It's a better name, not necessarily a better description, just like Shmem is a better name than shared_memory. It's also a better namespace name that is immediately usable without an alias. Just my opinion, of course. :-)
"Peter Dimov" <pdimov@mmltd.net> writes:
Rene Rivera wrote:
Peter Dimov wrote:
Ion Gaztañaga wrote:
[...]
for example), I'm proposing the Boost.IPC or Boost.InterProcess name (boost::ipc or boost::interprocess namespace).
I like IPC.
I don't like IPC, because the library is not just for communications. "InterProcess" seems like the most descriptive.
IPC > InterProcess, even for a library that is not just for communications. It's a better name, not necessarily a better description, just like Shmem is a better name than shared_memory.
Shptr<T> x(new T) ?? ;-) Seriously, why is "Shmem" better than "shared_memory?" -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
IPC > InterProcess, even for a library that is not just for communications. It's a better name, not necessarily a better description, just like Shmem is a better name than shared_memory.
Shptr<T> x(new T)
?? ;-)
shared_pointer<T> x( new T ); ? :-) shared_ownership_pointer<T> x( new T ); ?? :-)) Shptr<> is actually not that bad, but shared_ptr > Shptr because of the scoped/auto/weak_ptr relatives.
Seriously, why is "Shmem" better than "shared_memory?"
Because it's short and unique. You can still pronounce it "shared memory", if you like.
On Feb 19, 2006, at 1:40 PM, Ion Gaztañaga wrote:
Currently, following Boost.Thread interface, mutex lock and unlock functions are private, but I would prefer making them public, and implement a unique scoped lock class that can lock any "lockable" object (shared_mutex, shared_recursive_mutex, named_mutex). This general locker could be moved to boost utilities or be just for this library. Or do you consider "too dangerous" to have lock functions public?. This is a proposal based on Howard Hinnant's much more complete scoped_lock proposal (http://home.twcny.rr.com/hinnant/cpp_extensions/threads_move.html):
What the heck did you do with the movable interface?! ;-) -Howard PS: Congrats on the nice job on shmem.
Hi to all, Not that I've received a lot of feedback but I have to take some decisions to start working on Shmem recycling so this is your last change to stop this:
* Library name:
Although Peter likes IPC, I agree with Rene agree that InterProcess is much more descriptive (and pronounceable) so I'm taking Boost.InterProcess (boost::interprocess namespace, boost/interprocess and libs/boost/interprocess directories). I think namespace ipc = boost::interprocess; will be common, though.
* Class names: mmapped_file -> mapped_file
named_xxx_object -> xxx_services so shared_memory_services mapped_file_services heap_memory_services external_memory_services
-> Public lock/unlock functions? -> Merging 7 mutex types into 3? -> Merging 3 scoped_lock types into 1?
Like Peter has said, yes to all. Regards, Ion
Hi Ion,
* Library name:
Although Peter likes IPC, I agree with Rene agree that InterProcess is much more descriptive (and pronounceable) so I'm taking Boost.InterProcess (boost::interprocess namespace, boost/interprocess and libs/boost/interprocess directories). I think
namespace ipc = boost::interprocess;
will be common, though.
I agree with this choice.
* Class names: mmapped_file -> mapped_file
named_xxx_object -> xxx_services so
shared_memory_services mapped_file_services heap_memory_services external_memory_services
I haven't followed this portion of the discussion very closely, so maybe it's been discussed. But, what does the "_services" suffix really add? It just seems superfluous to me. Thanks for all of your work on this. Jeff Flinn
named_xxx_object -> xxx_services so
shared_memory_services mapped_file_services heap_memory_services external_memory_services
I haven't followed this portion of the discussion very closely, so maybe it's been discussed. But, what does the "_services" suffix really add? It just seems superfluous to me.
It doesn't say much but I pretend to give a name to "a shared memory/memory mapped/heap memory segment that can allocate/find/destroy named objects, raw memory and do more things". And it has to be short! Any suggestion? Thanks for your reply, Ion
Ion Gaztañaga wrote:
named_xxx_object -> xxx_services so
shared_memory_services mapped_file_services heap_memory_services external_memory_services I haven't followed this portion of the discussion very closely, so maybe it's been discussed. But, what does the "_services" suffix really add? It just seems superfluous to me.
It doesn't say much but I pretend to give a name to "a shared memory/memory mapped/heap memory segment that can allocate/find/destroy named objects, raw memory and do more things". And it has to be short!
Any suggestion?
Removing "_services" seems to be descriptive enough from my POV: boost::interprocess::shared_memory boost::interprocess::mapped_file boost::interprocess::heap_memory boost::interprocess::external_memory Do you really need to have it mean something more by adding a suffix? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Removing "_services" seems to be descriptive enough from my POV:
boost::interprocess::shared_memory boost::interprocess::mapped_file boost::interprocess::heap_memory boost::interprocess::external_memory
Do you really need to have it mean something more by adding a suffix?
The problem is that shared_memory and mapped_file already exist and those classes just create a shared memory segment and a mapped file (operating system wrappers just like a mutex). I'm talking about classes that above those they offer dynamic allocation and named object allocation in shared memory and memory-mapped files. "Services" may not be a correct name but I don't know how to express the functionality of those classes. Ion
On 2/25/06, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
* Library name: Although Peter likes IPC, I agree with Rene agree that InterProcess is much more descriptive (and pronounceable) so I'm taking Boost.InterProcess (boost::interprocess namespace, boost/interprocess and libs/boost/interprocess directories). I think
namespace ipc = boost::interprocess;
will be common, though. It seems to be a bit too long. Although, I understand the desire to make the name more descriptive...
* Class names: mmapped_file -> mapped_file
named_xxx_object -> xxx_services so
shared_memory_services mapped_file_services heap_memory_services external_memory_services I don't like "services" much, especially the plural form. The object of this class would be number of services or a single service? And after all, this class is just more convenient and high-level interface to lower-level interfaces, so I don't think "services" is a good name. Maybe just leave "named_" prefix, but cut out the "_object" which doesn't add much information. Then you will have named_shared_memory named_mapped_file named_heap_memory etc.
-- Best regards, Zigmar
I don't like "services" much, especially the plural form. The object of this class would be number of services or a single service? And after all, this class is just more convenient and high-level interface to lower-level interfaces, so I don't think "services" is a good name. Maybe just leave "named_" prefix, but cut out the "_object" which doesn't add much information. Then you will have named_shared_memory named_mapped_file named_heap_memory etc.
Some users have suggested more descriptive names: objects_in_shared_memory objects_in_mapped_file objects_in_heap_memory objects_in_user_memory A bit long but I think the class expresses very clearly its use. We can make it shorter with "objects_in_shmem"/"objects_in_mfile", but is not very pronounceable. This name issue is harder than the review! Comments? Best, Ion
At 6:37 PM +0100 2/27/06, =?UTF-8?B?SW9uIEdhenRhw7FhZ2E=?= wrote:
I don't like "services" much, especially the plural form. The object of this class would be number of services or a single service? And after all, this class is just more convenient and high-level interface to lower-level interfaces, so I don't think "services" is a good name. Maybe just leave "named_" prefix, but cut out the "_object" which doesn't add much information. Then you will have named_shared_memory named_mapped_file named_heap_memory etc.
Some users have suggested more descriptive names:
objects_in_shared_memory objects_in_mapped_file objects_in_heap_memory objects_in_user_memory
A bit long but I think the class expresses very clearly its use. We can make it shorter with "objects_in_shmem"/"objects_in_mfile", but is not very pronounceable. This name issue is harder than the review! Comments?
This may be yet another half-backed idea, but, how different is the existing "primitive" shared_memory class from a basic_named_shared_object instantiation over a "null" memory algorithm, i.e. a memory algorithm that doesn't actually provide any allocation support? Could they be made to be the same if they aren't presently? That might permit the elimination of a level, which might then make naming easier. Some more alternatives in the naming scheme race: - xxx_with_allocation, i.e. shared_memory_with_allocation, heap_with_allocation - managed_xxx, i.e. managed_shared_memory, managed_heap Both of these are attempting to get across the idea that the differentiator between them and the underlying primitive shared_memory, heap memory, ... is that these higher level constructs provide support for managing allocation from the raw block of memory.
Pavel Vozenilek(e)k dio:
- managed_xxx, i.e. managed_shared_memory, managed_heap
Not "managed" please. Copyrighted by Microsoft, suggests association with .NET.
Sorry, I've missed this mail when replying Kim's "managed" proposal and its enemies! Ion
why not default all named objects and if there's anonymous then prefix that with anon: eg shmem (shared mem) mfile (mem mapped) gamem (global/heap alloc mem) uamem (user alloc mem) and if these apply: anon_shmem anon_mfile etc.. ----- Original Message ----- From: "Kim Barrett" <kab@irobot.com> To: <boost@lists.boost.org> Sent: Tuesday, February 28, 2006 8:08 AM Subject: Re: [boost] [interprocess, aka shmem] Some proposals for open issues from the review
named_shared_memory named_mapped_file named_heap_memory etc.
Some users have suggested more descriptive names:
objects_in_shared_memory objects_in_mapped_file objects_in_heap_memory objects_in_user_memory
A bit long but I think the class expresses very clearly its use. We can make it shorter with "objects_in_shmem"/"objects_in_mfile", but is not very pronounceable. This name issue is harder than the review! Comments?
Some more alternatives in the naming scheme race:
- xxx_with_allocation, i.e. shared_memory_with_allocation, heap_with_allocation
- managed_xxx, i.e. managed_shared_memory, managed_heap
Send instant messages to your online friends http://au.messenger.yahoo.com
On 2/27/06, m_phanivong@yahoo.com.au <m_phanivong@yahoo.com.au> wrote:
shmem (shared mem) mfile (mem mapped) gamem (global/heap alloc mem) uamem (user alloc mem)
Personally I find those abbreviations excessively obtuse. I don't mind _mem, but I really don't like m, ga, or ua. _mem reminds be of _ptr, so what about shared_mem, file_mem, heap_mem, and user_mem ( or similar? ) ~ Scott
This may be yet another half-backed idea, but, how different is the existing "primitive" shared_memory class from a basic_named_shared_object instantiation over a "null" memory algorithm, i.e. a memory algorithm that doesn't actually provide any allocation support? Could they be made to be the same if they aren't presently? That might permit the elimination of a level, which might then make naming easier.
Well, currently there is a possibility of a null index type, not a null algorithm. But even if that can be compatible we have several problems: The real space the user can overwrite is dependent on the "null" size of the memory algorithm and the null index. The compilation of all that structure for a user that just want to create a shared memory segment would be an overkill. I think that a simple shared_memory primitive (that just creates a segment and maps it) is useful because we have other operating system primitives (mapped file, mutex, semaphore).
Some more alternatives in the naming scheme race:
- xxx_with_allocation, i.e. shared_memory_with_allocation, heap_with_allocation
- managed_xxx, i.e. managed_shared_memory, managed_heap
I don't have any problem with these proposals. But "managed" seems to be too overused to some users.
Both of these are attempting to get across the idea that the differentiator between them and the underlying primitive shared_memory, heap memory, ... is that these higher level constructs provide support for managing allocation from the raw block of memory.
Yes, but it also allows anonymous object construction, named object construction and other features. I like "managed_shared_memory" because is shorter than other alternatives and compatible with the "segment_manager" concept. Any "managed_xxx" enemy out there? Ion
At 5:50 PM +0100 2/28/06, Ion Gaztañaga wrote:
The real space the user can overwrite is dependent on the "null" size of the memory algorithm and the null index. The compilation of all that structure for a user that just want to create a shared memory segment would be an overkill.
I think that a simple shared_memory primitive (that just creates a segment and maps it) is useful because we have other operating system primitives (mapped file, mutex, semaphore).
At present the "simple" shared_memory already has a header region. I'm not sure what is there, other than the reference count (which I need to follow up on later). I haven't looked at mapped file in that regard.
Both of these are attempting to get across the idea that the differentiator between them and the underlying primitive shared_memory, heap memory, ... is that these higher level constructs provide support for managing allocation from the raw block of memory.
Yes, but it also allows anonymous object construction, named object construction and other features. I like "managed_shared_memory" because is shorter than other alternatives and compatible with the "segment_manager" concept. Any "managed_xxx" enemy out there?
I was thinking of the various kinds of object allocation and such as being specific instances of the broad class of "managing allocation". I think a relatively generic term is needed here because there are lots of different detailed bits of functionality to be covered by the name.
On 2/27/06, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
named_shared_memory named_mapped_file named_heap_memory etc.
Some users have suggested more descriptive names:
objects_in_shared_memory objects_in_mapped_file objects_in_heap_memory objects_in_user_memory I don't exactly understand where plural form cames from. Isn't, for example, current named_shared_object references _single_ shared memory block?
-- Best regards, Zigmar
On 2/27/06, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
named_shared_memory named_mapped_file named_heap_memory etc. Some users have suggested more descriptive names:
objects_in_shared_memory objects_in_mapped_file objects_in_heap_memory objects_in_user_memory I don't exactly understand where plural form cames from. Isn't, for example, current named_shared_object references _single_ shared memory block?
Yes, but you create named/anonymous "objects" or "instances" of classes using construct<> functions. That's why they have proposed "objects". Best, Ion
On 2/28/06, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
I don't exactly understand where plural form cames from. Isn't, for example, current named_shared_object references _single_ shared memory block?
Yes, but you create named/anonymous "objects" or "instances" of classes using construct<> functions. That's why they have proposed "objects". I know, but I think even if the instance of this class allows creating multiple objects of other types, doesn't turn the object itself on multiple objects. It just the same factory object that can "generate" others.
-- Best regards, Zigmar
participants (12)
-
David Abrahams -
Howard Hinnant -
Ion Gaztañaga -
Jeff Flinn -
Kim Barrett -
m_phanivong＠yahoo.com.au -
me22 -
Pavel Antokolsky aka Zigmar -
Pavel Vozenilek -
Peter Dimov -
Rene Rivera -
Stefan Seefeld