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. > > 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.
I don't know at the moment, because the cluster I'm working on is temporarilly out of service, so that I can't login. > What are the downsides of 1.)? Intuitively I would not think that waiting for a request automatically frees this request. However, if you guys are sure that it is guaranteed to do so, this is of course no problem. The other point is that somebody might create a request and then not wait for it. On the other hand, I can't think of any situation in which this should be a sensible thing to do. > 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, Yes, sure. > although I don't think there is anywhere we need to actually use it. Right. Best Regards, Tim -- Dr. Tim Kroeger CeVis -- Center of Complex Systems and Visualization University of Bremen [email protected] Universitaetsallee 29 [email protected] D-28359 Bremen Phone +49-421-218-7710 Germany Fax +49-421-218-4236 ------------------------------------------------------------------------------ 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
