https://svn.boost.org/trac10/ticket/1975 <p> <a class="ext-link" href="http://svn.boost.org/svn/boost/trunk/boost/interprocess/windows_shared_memory.hpp"><span class="icon">​</span>http://svn.boost.org/svn/boost/trunk/boost/interprocess/windows_shared_memory.hpp</a> windows_shared_memory::priv_open_or_create() is the function that calls <a class="missing wiki">CreateFileMapping</a>() to reserve a segment of virtual memory. It does not specify either SEC_RESERVE or SEC_COMMIT, and the docs for <a class="missing wiki">CreateFileMapping</a>() say that SEC_COMMIT is assumed. </p> <p> 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. </p> <p> 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. </p> <p> 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). </p> <p> SEC_RESERVE should be used instead. This is more complicated because then you need to do <a class="missing wiki">VirtualAlloc</a> 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). </p> <p> 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. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/1975 Trac 1.4.3 Ion Gaztañaga Fri, 30 May 2008 15:25:24 GMT https://svn.boost.org/trac10/ticket/1975#comment:1 https://svn.boost.org/trac10/ticket/1975#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">invalid</span> </li> </ul> <p> I don't consider this a bug, but a feature. Managing pages on-demand is not a feature currently provided by Interprocess and I find difficult this to be managed by Interprocess. </p> <p> As mentioned, an alternative would be to use several managed segments created on demand by the user. </p> Ticket Jason Sachs <jsachs@…> Fri, 30 May 2008 16:06:29 GMT https://svn.boost.org/trac10/ticket/1975#comment:3 https://svn.boost.org/trac10/ticket/1975#comment:3 <ul> <li><strong>status</strong> <span class="trac-field-old">closed</span> → <span class="trac-field-new">reopened</span> </li> <li><strong>resolution</strong> <span class="trac-field-deleted">invalid</span> </li> </ul> <p> Replying to <a class="ticket" href="https://svn.boost.org/trac10/ticket/1975#comment:1" title="Comment 1">igaztanaga</a>: </p> <blockquote class="citation"> <p> I don't consider this a bug, but a feature. Managing pages on-demand is not a feature currently provided by Interprocess and I find difficult this to be managed by Interprocess. </p> <p> As mentioned, an alternative would be to use several managed segments created on demand by the user. </p> </blockquote> <p> I hope you won't take offense if I reopen this. I do agree that managing arbitrary pages on demand is something unreasonable. However, the problem I'm facing, and the only thing I'm looking for a resolution, is the implications of (a) having to specify a fixed maximum size for the segment, despite possible/probable usage that is much smaller and (b) the Boost library's only option is to commit all that virtual memory at once in Windows. </p> <p> I've looked around a little bit at the source files for boost::interprocess and it looks like there some facilities in <a class="ext-link" href="http://svn.boost.org/svn/boost/trunk/boost/interprocess/detail/managed_memory_impl.hpp"><span class="icon">​</span>http://svn.boost.org/svn/boost/trunk/boost/interprocess/detail/managed_memory_impl.hpp</a> to grow() file sizes. The memory reserved by <a class="missing wiki">CreateFileMapping/MapViewOfFile</a> can't grow, but what if there were a separate "size" and "max_size" in <a class="ext-link" href="http://svn.boost.org/svn/boost/trunk/boost/interprocess/mapped_region.hpp"><span class="icon">​</span>http://svn.boost.org/svn/boost/trunk/boost/interprocess/mapped_region.hpp</a> ? (which appears to be the class that calls <a class="missing wiki">MapViewOfFile</a> via map_view_of_file_ex()) "max_size" would represent the argument passed to <a class="missing wiki">CreateFileMapping</a> (with the SEC_RESERVE flag) / <a class="missing wiki">MapViewOfFile</a>, and "size" representing the portion of that memory allocated; calls to grow() would call <a class="missing wiki">VirtualAlloc</a>, not in a haphazard random-access per-page way, but merely to increase the size used by the shared memory segment, in a sequential, linear (or exponential if that makes sense) fashion. </p> Ticket anonymous Wed, 25 Mar 2009 18:08:04 GMT https://svn.boost.org/trac10/ticket/1975#comment:4 https://svn.boost.org/trac10/ticket/1975#comment:4 <ul> <li><strong>status</strong> <span class="trac-field-old">reopened</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> </ul> <p> This feature won't be implemented because of complexity and time constraints. </p> Ticket