MPI_Iconsume_counter Request completion

Dick Treumann (treumann@kgn.ibm.com)
Tue, 18 Jun 1996 16:41:44 -0400

At the June meeting the Forum voted to endorse the set of functions:
MPI_Get_counter(comm,count)
MPI_Consume_counter(comm,count)
MPI_Iconsume_counter(comm,count,&request)
As this vote was taken it was recognized that the proposal did not
define the semantic for completion of MPI_Iconsume_counter or whether
we could allow more than one Iconsume against a particular counter.

My initial view was that it would be reasonable for a task to post an
Iconsume with a high trigger value or threshold. Perhaps it would even
associate a handler with reaching this high threshold. Reaching the
Iconsume value would mean "it is time to react NOW". While the
Iconsume was pending the task might routinely call MPI_Get_counter
followed by MPI_Consume_counter, using the Get_counter result to
process whatever had happened so far. In this usage, the Iconsume would
only be used to catch the case of a flood of counter bumps which the
routine get/consume may not pick up soon enough.

This would not be safe if there is a potential for the counter value to
be reduced asynchronously by Iconsume completion. If we ignore
handlers we could specify that counter reduction for an Iconsume occurs
at the Wait or Test, not under the covers. It would be legal to post
more than one Iconsume on a single counter and a Wait or Test which
only used one of the requests would work predictabably. MPI would
specify that a Wait or Test which used > 1 requests for a single
counter would behave as if all requests were tried in some undefined
order. Users would be advised to never combine blocking Consume with
Iconsume handlers.

There is a second option which I expect everyone to love ;-). That is,
state that when a counter reaches a level which satisfies a posted
Iconsume, the Iconsume is marked complete and the counter reduced. The
completion order for multiple Iconsumes is less obvious but could be
specified as "when a counter increases to a level which satisfies at
least one Iconsume request, the largest satisfiable request completes
followed by the next largest satisfiable request until the count is
decreased to a level which will not satisfy any remaining request." In
this model Iconsume requests, with or without handlers, generate
asynchronous reductions in counter value. This leads to the "fun"
part. MPI_Consume_counter gets a HARD/SOFT flag or there is a similar
soft function.

Without some way to do a soft MPI_Consume_counter I do not see a way to
safely use Consume on a counter when that same counter can be reduced
asyncronously by an Iconsume completing. 

-- 
Dick Treumann                               POWER Parallel Systems
(Internet) treumann@kgn.ibm.com             IBM  -- Poughkeepsie, NY
(VNET)     TREUMANN at KGNVMC               Tel: (914) 433-7846
(internal) treumann@windsurf.kgn.ibm.com    Fax: (914) 433-8363