[shmem] Some proposals for open issues from the review

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[shmem] Some proposals for open issues from the review

Ion Gaztañaga
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









_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [shmem] Some proposals for open issues from the review

Peter Dimov
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [shmem] Some proposals for open issues from the review

Rene Rivera
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [shmem] Some proposals for open issues from the review

Stefan Seefeld
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [shmem] Some proposals for open issues from the review

Peter Dimov
In reply to this post by Rene Rivera
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. :-)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [shmem] Some proposals for open issues from the review

David Abrahams
"Peter Dimov" <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [shmem] Some proposals for open issues from the review

Peter Dimov
David Abrahams wrote:
> "Peter Dimov" <[hidden email]> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [shmem] Some proposals for open issues from the review

Howard Hinnant
In reply to this post by Ion Gaztañaga
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

[interprocess, aka shmem] Some proposals for open issues from the review

Ion Gaztañaga
In reply to this post by Ion Gaztañaga
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [interprocess, aka shmem] Some proposals for open issues from the review

Jeff Flinn
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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [interprocess, aka shmem] Some proposals for open issues from the review

Ion Gaztañaga
>> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [interprocess, aka shmem] Some proposals for open issues from the review

Rene Rivera
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [interprocess, aka shmem] Some proposals for open issues from the review

Ion Gaztañaga
> 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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [interprocess, aka shmem] Some proposals for open issues from the review

Zigmar
In reply to this post by Ion Gaztañaga
On 2/25/06, Ion Gaztañaga <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [interprocess, aka shmem] Some proposals for open issues from the review

Ion Gaztañaga
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [interprocess, aka shmem] Some proposals for open issues from the review

Kim Barrett
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [interprocess, aka shmem] Some proposals for open issues from the review

Pavel Vozenilek

> - managed_xxx, i.e. managed_shared_memory, managed_heap
>

Not "managed" please. Copyrighted by Microsoft,
suggests association with  .NET.

/Pavel



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [interprocess, aka shmem] Some proposals for open issues from the review

Minh Phanivong
In reply to this post by Kim Barrett

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" <[hidden email]>
To: <[hidden email]>
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 
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [interprocess, aka shmem] Some proposals for open issues from the review

me22
On 2/27/06, [hidden email] <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [interprocess, aka shmem] Some proposals for open issues from the review

Zigmar
In reply to this post by Ion Gaztañaga
On 2/27/06, Ion Gaztañaga <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12