[Pvfs2-developers] Trove patches

[Phil Carns]

Julian Martin Kunkel wrote:
> Hi,
> 
>>status?  The state of the operation is already gone, so you can't
>>distinguish between the caller giving you a bogus ID and the caller
>>giving you the ID of something that recently completed.  The thread that
>>called test() assuming that the operation would be there will probably
>>be confused by the result either way.
> 
> I was also talking about the interference between cancel and test calls.
> Right, you can't tell if the ID is bogus or recently completed if you run 
> multiple test calls. 
> However, I think that is much better than accessing invalid / undefined memory 
> because that makes it hard to find the problem, in case you call test 
> functions after another. Also the application knows if it has posted the ID 
> before, so a return value like "completed or invalid ID" means something to 
> the app.
> In terms of MPI multiple MPI_TEST calls of an already finished request return 
> an error to the caller because the request is invalidated (set to 
> MPI_REQUEST_NULL) once it is completed and mpi_test is called. That would be 
> a similar semantics to trove with gen_safe.
> I like the explainations you write with poll and I agree if you call both test 
> functions at the same time then it is bad practise / undefined which one gets 
> the right status. 

Ok, I think we are on the same page then.

I misread which potential race condition you were talking about.  I 
don't think that cancel() is a particularly dangerous case, though, 
because it doesn't actually destroy any operations- it just moves them 
to a completion queue to later be cleaned up by a normal test() or 
testcontext() call.  By itself it shouldn't lead to corruption with the 
test() call.

Just to clarify where I am coming from, I don't mind if the calls are 
made safer from a debugging/development point of view.  I also don't 
have any clue what the performance difference really is between the id 
generator implementations.  I just wanted to make sure that this wasn't 
being done to encourage the API to be used in a bad way.  The 
test/testcontext approach is used in a whole pile of internal interfaces 
within PVFS2, so it would be good if we try to keep up the semantic 
assumptions consistent across the board.

-Phil