>> 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.
I'm all for (1). Note thought that MPI_Request_free does not cancel communication - MPI_Cancel does. MPI_Request_free says you have no need for this particular request - possibly because you will be able to infer when it has completed due to some knowledge of program structure. MPI_Cancel is definitely not used in our code and according to the docs 'can be an expensive operation that should be used only exceptionally.' So what about Request::free() and a clean destructor? -Ben ------------------------------------------------------------------------------ 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
