[boost] [shmem] Some proposals for open issues from the review

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-02-19 13:40:51

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