On Thu, Nov 4, 2010 at 8:52 AM, Roy Stogner <[email protected]> wrote: > > On Thu, 4 Nov 2010, Kirk, Benjamin (JSC-EG311) wrote: > >>>> Long-term, there are two policy options that I think make sense: >>>> >>>> 1. Don't ever do MPI_Request_free implicitly from a Request object. >>>> >>>> 2. Do reference counting in Request objects; do an MPI_Request_free >>>> when the last reference is destroyed. >>>> >>>> I can see pros and cons to each; I'd appreciate others' opinions. >>> >>> I like #2, but the question is, how much overhead that will produce. >>> My feeling is that it is negligible, but I might be wrong. >> >> Since requests are associated with interprocessor communication I am sure >> the overhead associated with reference counting is trivial in comparison. > > Ben's exactly right. > > My only concern with #2 is the implicit shared reference behavior > between Request objects and MPI_Request objects. I could imagine > someone using a raw MPI_Request to initiate an operation, creating a > Request from it, letting the Request go out of scope (freeing the > underlying request), then expecting the MPI_Request to still be useful > afterwards. Kind of a stretch, but if there are unlikely failure > cases that I can quickly come up with I worry that there might be > subtle failure cases I just haven't spotted yet.
I don't think we should worry about reference counting. It's tricky and error prone (as you have shown). In normal MPI code there is almost never a need to cancel an Isend/Irecv, so I think our Request object should just be a wrapper around the MPI_Request and not attempt to manage lifetime in any way. It's true that it's just as easy to leak resources as it was with a naked MPI_Request object, but I'd argue that just doesn't happen too often. Plus, if we provide the Request::free() interface, at least we're giving the user no extra excuses to leak the requests. The documentation should make clear that Request::free() should only be used to cancel an Isend/Irecv, and that all Requests should be waited on before being allowed to go out of scope, just like they are in normal MPI code. -- John ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
