Re: In repsonse to Carleton

I'm also sending below some of my questions on the msg-passing API from
http://www.jlab.org/~watson/lqcd/MessageAPI.htm   (version 0.7)

Regards,

-Celso

=======================================================================

1) First, a few questions related to Carleton's recent questions:

>   (a) In particular, in the the MPI_Irecv command, one specifies the
>   source node as well as a message label.  In this way it is
>   possible for messages of the same type from more than one source
>   to arrive asynchronously, and be distinguished.  I do not see this
>   capability in the Version 0.7 document.

  Does the API assume that, in the application, different sources
  will be sending to different buffers of a certain node? If this
  is true, I can understand the proposed scheme. If not, I would
  agree with Carleton, there might be a problem.

>   (b) If more than one message of a given type might arrive at a
>   given node in a communication operation, it would be incorrect to
>   assign it a specific buffer, lest a second arriving message
>   clobber the first.

  I have a general question related to this. Could such messages
  come from the same source? Assuming the non-blocking semantics
  for the "startSend" operation, would the sender know that the
  first message had been received, and a new one could be sent?
  I believe that "testCompletion" would simply mean that the
  sending buffer can be reused, right? What is the expected
  mechanism to avoid this clobbering issue with the optimized
  messages?

2) In the "Communications Declarations" part, a contiguous buffer
   is allocated and associated to a handle of type "DECBUF" by
   the 'allocateBuffer' call. Why is this necessary? Couldn't
   contiguous and strided buffers have the same treatment? (i.e.
   be allocated by traditional means, then associated to a handle
   by the 'declare*' calls)

3) In the paragraph just before "Generalized Messaging Operations",
   the text says that "It will be necessary (for strided calls on
   a non-strided machine) for the user to call one of these two
   routines to finish the receive operation".
   Why is this so only for "strided calls on a non-strided machine"?
   With a non-blockig receive, isn't this always necessary for any
   receive operation, independently of the type of buffer or platform?

4) It's unclear to me the meaning of the "int map[]" argument in
   the call 'declareSendMap'. Is this a map valid for the local
   node only? Are these maps the same across all nodes?

5) In the 'getNextMessage' call, the message is always returned in
   a contiguous buffer, of size 'buflen'. What happens if originally
   this message had been sent from a strided buffer? Is it assumed
   that strided buffers cannot be used at all, in this generalized
   messaging scheme?


_______________________________________________
QCDapi mailing list
QCDapi@physics.bu.edu
http://physics.bu.edu/mailman/listinfo/qcdapi