On Thu, 4 Nov 2010, Roy Stogner wrote:
>
> On Thu, 4 Nov 2010, Tim Kroeger wrote:
>
>> On Thu, 4 Nov 2010, Kirk, Benjamin (JSC-EG311) wrote:
>>
>>> 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
On Thu, 4 Nov 2010, Tim Kroeger wrote:
> On Thu, 4 Nov 2010, Kirk, Benjamin (JSC-EG311) wrote:
>
>> 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
On Thu, 4 Nov 2010, Kirk, Benjamin (JSC-EG311) wrote:
> 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.
The cluster is alive again. I'm using:
g++ (GCC) 4.1.2
mpich2-1.2
--
Dr. Tim Kroeger
CeVis -- Center of Comple
On Thu, 4 Nov 2010, Kirk, Benjamin (JSC-EG311) wrote:
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 t
>> 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 reques
On Thu, Nov 4, 2010 at 8:52 AM, Roy Stogner 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 R
On Thu, 4 Nov 2010, Roy Stogner wrote:
> Could we add a libmesh_assert to the destructor, to make sure the
> request has been set to MPI_REQUEST_NULL (which I believe both the
> wait and free commands do)?
No, we can't. (-:
Because the current usage (that started this discussion) would be
ca
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
On Thu, 4 Nov 2010, Kirk, Benjamin (JSC-EG311) wrote:
> What are the downsides of 1.)?
I'd also like to know this one. It looks as if the only downside is a
memory leak in the case where a user accidentally ignores a Request
rather than waiting for it to complete? And in that case we can just
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 refe
>>> 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 t
>> 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;
On Wed, 3 Nov 2010, Roy Stogner 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 ca
13 matches
Mail list logo
