[Boost-bugs] [Boost C++ Libraries] #1975: windows_shared_memory implicitly commits virtual memory

Subject: [Boost-bugs] [Boost C++ Libraries] #1975: windows_shared_memory implicitly commits virtual memory
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2008-05-30 14:42:33

#1975: windows_shared_memory implicitly commits virtual memory
---------------------------------------------------+------------------------
 Reporter:  Jason Sachs <jsachs_at_[hidden]>  |       Owner:  igaztanaga  
     Type:  Bugs                                   |      Status:  new         
Milestone:  Boost 1.36.0                           |   Component:  interprocess
  Version:  Boost 1.35.0                           |    Severity:  Problem     
 Keywords:                                         |  
---------------------------------------------------+------------------------
 http://svn.boost.org/svn/boost/trunk/boost/interprocess/windows_shared_memory.hpp

 windows_shared_memory::priv_open_or_create() is the function that calls
 CreateFileMapping() to reserve a segment of virtual memory. It does not
 specify either SEC_RESERVE or SEC_COMMIT, and the docs for
 CreateFileMapping() say that SEC_COMMIT is assumed.

 Either this is a small bug and SEC_COMMIT should be specified explicitly
 (w/ no change in behavior or other code needed), or there is a larger
 problem and SEC_RESERVE should be used instead.

 The problem with SEC_COMMIT is as follows.
 Suppose you have a N processes where each process i=0,1,...N-1 is going to
 need a pool of related memory with a maximum usage of sz[i] bytes, where
 sz[i] is not known beforehand but is guaranteed less than some maximum M,
 and has a mean expected value of m where m is much smaller than M. From a
 programmer's standpoint, the best way to handle this would be to reserve a
 single shared memory segment and ask Boost::interprocess to make the
 segment size equal to M.

 But if I use the existing boost libs to do this, then because SEC_COMMIT
 is used, my total system resource usage for virtual memory is N*M (instead
 of sum(sz[i]) which is likely to be much smaller).

 SEC_RESERVE should be used instead. This is more complicated because then
 you need to do VirtualAlloc or something later to actually commit the
 memory on-demand (in fact I'm not quite sure how this would have to work
 esp. since I'm unfamiliar w/ the inner workings of Boost::interprocess).

 as an aside, it would be helpful for me to find out sooner rather than
 later whether this is considered a valid bug that can be addressed in the
 coming months; otherwise I would have to change my architecture + use
 multiple shared memory segments in order to make more efficient use of the
 limited total system resource of virtual memory.

-- 
Ticket URL: <http://svn.boost.org/trac/boost/ticket/1975>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.