upcxx::progress_required not implemented

[Dan Bonachea]

#include <upcxx/upcxx.hpp>

int main() {
  upcxx::init();
  bool b = upcxx::progress_required();
  upcxx::finalize();
  return 0;
}

g++ progressrequired.cpp -DUPCXX_BACKEND=gasnet1_seq -D_GNU_SOURCE=1 -DGASNET_SEQ -I/home/pcp1/bonachea/UPC/inst-upcxx/gasnet.opt/include -I/home/pcp1/bonachea/UPC/inst-upcxx/gasnet.opt/include/smp-conduit -I/home/pcp1/bonachea/UPC/inst-upcxx/upcxx.O3.gasnet1_seq.smp/include -std=c++11 -Wno-inline -O3 --param max-inline-insns-single=35000 --param inline-unit-growth=10000 --param large-function-growth=200000 -Winline -Wno-unused -Wno-unused-parameter -Wno-address -std=c++11 -Wno-inline -L/home/pcp1/bonachea/UPC/inst-upcxx/upcxx.O3.gasnet1_seq.smp/lib -lupcxx -lpthread -L/home/pcp1/bonachea/UPC/inst-upcxx/gasnet.opt/lib -lgasnet-smp-seq -lrt -L/usr/local/pkg/gcc/7.2.0/lib/gcc/x86_64-pc-linux-gnu/7.2.0 -lgcc -lm -o progressrequired
progressrequired.cpp: In function 'int main()':
progressrequired.cpp:5:19: error: 'progress_required' is not a member of 'upcxx'
   bool b = upcxx::progress_required();
                   ^~~~~~~~~~~~~~~~~
progressrequired.cpp:5:19: note: suggested alternative: 'progress_level'
   bool b = upcxx::progress_required();
                   ^~~~~~~~~~~~~~~~~
                   progress_level

[Former user]

For expedience, I can simply make progress_required() always return true, but according to the spec, would that require discharge() to infinite loop. I vote that we diverge from the spec momentarily and make progress_required() true and discharge() a nop anyway.

[Former user]

Or would it be preferable to leave these as not implemented in this release. The big implication is not having a guarantee from the runtime that its safe for a thread to block on some condition (like sleeping in a pool) before entering upcxx again.

[Dan Bonachea]

If you are always injecting immediately and never queuing outgoing requests, isn't it correct for progress_required() to always return false?

If you are queuing outgoing requests somewhere, then progress_required() should return true iff queue.nonempty() for any of the selected personas.

If we are queuing and the giving right answer is hard, it seems better to leave it unimplemented than to implement something we know is a lie that can lead to hangs.

[Former user]

We arent queueing, but we do have initiator chaining for put_then_rpc which would require us to track a count of outstanding rpc's. But we also arent advertising put_then_rpc as a functioning capability, so we can just implement progress_required()=false. Right?

[Dan Bonachea]

Sounds reasonable to me - I don't think we've explicitly disclaimed put_then_rpc, but we know it's being renamed with generalized completion so we should probably add it to the "unimplemented" list.

If that's the only exception then implementing it as progress_required()=false seems reasonable (and discharge should probably be implemented using the code exactly from the spec, making it a no-op for now)

[Former user]

Fixed issue 74. Fixed issue 75.

→ <<cset 9d8c9335f818>>