>>> 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.
Tim - what compiler and MPI are you using? I'd like to make sure I can repeat this before declaring we know how to fix it. What are the downsides of 1.)? When I implemented the request object I clearly misinterpreted the purpose of MPI_Request_free(). We should add a member Request::free() to do what the current destructor does, although I don't think there is anywhere we need to actually use it. -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
