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
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
