Re: [boost] FW: Boost Digest, Vol 2929, Issue 4

Subject: Re: [boost] FW: Boost Digest, Vol 2929, Issue 4
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-06-04 00:12:52

On 6/3/2010 4:29 PM, Bartlett, Roscoe A wrote:
> David,
>
> I have some responses below ...
>
>> ------------------------------
>>
>> Message: 13
>> Date: Tue, 01 Jun 2010 16:16:25 -0400
>> From: David Abrahams<dave_at_[hidden]>
>> To: boost_at_[hidden]
>> Cc: "mathias.gaunard_at_[hidden]"<mathias.gaunard_at_[hidden]>
>> Subject: Re: [boost] Review of a safer memory management approach for
>> 	C++?
>> Message-ID:<m2hblmcxuu.wl%dave_at_[hidden]>
>> Content-Type: text/plain; charset=UTF-8
[...]
>> I would like to see an example of a design with shared object
>> ownership that is ?much less complex? than all other functionally
>> equivalent designs that eschew shared ownership.  I'm not saying such
>> applications don't exist, but IME they are rare, and a concrete
>> example would help to bring this whole discussion back to earth.
>
> [Bartlett, Roscoe A]
>
> One design where shared mutable objects likely makes things overall simpler and more natural is the PDE expression mechanism in the Sundance code (http://www.math.ttu.edu/~klong/Sundance/html/).  If the clients all expect remote updates of shared objects, then things work great.  The problem is when an object is changed by another client and you don't expect it to change (i.e. the classic problem of change propagation).
>
> As for sharing of objects, it is critical for many types of software in the Computational Science and Engineering (CSE) domain.  You have to share large objects in order to cut down on runtime and storage overhead.  As one example, consider the Petra object model with the Trilinos packages Epetra and Tpetra (http://trilinos.sandia.gov/).  In the Petra object model, you have objects with significant storage overhead like Maps and Graphs that are shared between many different objects like Vectors, MultiVectors, and Matrices.  Yes, you could create deep copies of Maps and Graphs but that would waste a large amount of storage.  The bottom line is that by sharing large objects like Maps and Graphs instead of making large numbers of copies, we can fit and solve much larger simulation problems on a computer than we could otherwise.  You could template and statically allocate everything and you will never get around the fundamental need to share the data contained in large objects
 in
>    these types of applications.
>
> Note, however, that Maps in Epetra/Tpetra are shared as const immutable objects.  That means that no-one can change a Map after it is first created.  Therefore, all of the problems with unexpected updates goes away (as you mention above).  However, the shared Maps must go away when they are not needed anymore and that is what the Teuchos::RCP class makes easy and robust.  Under the covers, Tpetra uses Tpetra::ArrayRCP for similar purposes and much more.  The situation with Graphs is different and issues of change propagation of shared objects are still present in some cases.
>
> Come to think of it, most of the object sharing that used in the CSE software that I use and write mostly just share const immutable objects so problems of change propagation mostly goes away.  However, there are some important use cases where all of the clients are not holding RCPs to const objects and the problem of change propagation remains.  Again, to save in significant runtime and storage overhead, we can't just create deep copies of all of these objects.  Templating and purely stack-based programs are not going to solve that problem.
>
> The Teuchos MM approach, I believe, largely solves the memory management problems with dynamic memory allocation and object sharing while still yielding very high performance and mostly eliminating undefined behavior associated with the incorrect usage of memory.  The most significant contribution of the Teuchos MM approach is the presents of Teuchos::Ptr and Teuchos::ArrayView and how they interact with the other classes.
>
> Cheers,
>
> - Ross

I don't see how shared object *ownership* is necessary in this 
example... :/  I don't think Dave was arguing that holding large objects 
by reference, or even dynamically allocating objects (large or not), is 
necessarily complex or "bad"...

Or did I miss something?

- Jeff