On 09/21/2011 04:45 AM, ?????? ???????????? wrote:
Hi!
How to create and remove bmi operations when sending or receiving
messages and how to handle it in test function? AFAIK, it is necessary
to create operation with bmi_alloc_method_op if send or receive
completes non-immediately.
That is correct.
then it must fill fields of operation structure and assign
op->user_ptr to user_ptr passed to function and register operation by
adding it to my method's operation list with op_list_add.
Technically you aren't required to store the user_ptr in that specifc
spot or use the op_list to track your operations, but that is the way
most methods do it. The only real requirement is that you can find the
operation later when the caller tests for completion, and that when the
operation completes you provide the same user_ptr as was given at post time.
then in test function it is necessary to search for operation
corresponding to given id with id_gen_fast_lookup and if operation
finished remove it from operation list with op_list_remove and
deallocate resources.
That is the usual way to do things but as I mentioned before you aren't
strictly required to use an op_list. Its just there for convenience if
you want it. Most methods that do use op_lists use several of them at
the same time for different purposes (send queues, receive queues,
completed operation queues, etc.)
but some functions that calling testcontext, e.g. bmi_thread_function,
checks for callback that must be assigned to user_ptr returned by
testcontext and it is looks like it work if I assign op->user_ptr to
user_ptr passed to test function.
Yes, this is correct. This is an example of a BMI caller associating
some extra information with the operation by way of the user_ptr.
Can anyone explain creation of operation, addition it to operation
list, deletion it from op list
It sounds like you have this part sorted out already...
and releasing resources used by this op in details
The only rule here is that during the test(), testsome(), or
testcontext() call you must free the op structure whenever you indicate
that the corresponding operation is done. That is really the only time
that you can free an operation. The caller should never try to access
the operation again once you have indicated that it si complete. There
is a bmi_dealloc_method_op() function that you can use to free the op
structure, but if you have malloc'd any additional memory that the op
refers to then you are responsible for freeing that memory as well.
and explain what to do with cancelled operations?
This is one of the trickier operations in terms of semantics. The
BMI_cancel() should be thought of as a suggestion to BMI that the
operation be cancelled. The caller still has to find out the status of
the operation afterwards by calling test(), testsome(), or
testcontext(). If someone calls cancel() on an operation that has
already completed (but hasn't been tested yet) then its Ok to return a
successful error code in the test() calls. In fact any error code out
of test is still valid at that point. If the BMI method does cancel the
operation, then it should set the error code to -BMI_ECANCEL, though.
Ideally the cancel will take effect immediately so that if you test
right after the cancel you will get an error for the operation, but
depending on your network layer this might be difficult to achieve :)
If the cancel takes longer perform, that's ok. You can also simply have
cancel() return success and do nothing, especially in the prototype
stage. The code won't technically break, but you run the risk of having
clients hang or servers leak resources in failure scenarios.
-Phil
Thanks,
Mikhail Gilmendinov
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
