upcxx::progress_required not implemented
#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
Comments (7)
-
Account Deleted -
Account Deleted 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.
-
reporter 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.
-
Account Deleted 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?
-
reporter 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)
-
Account Deleted - changed status to resolved
Fixed issue 74. Fixed issue 75.
→ <<cset 9d8c9335f818>>
-
-
assigned issue to
-
assigned issue to
- Log in to comment
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.