[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"doc-detail-84543-en":3,"doc-seo-84543-105":29,"detail-sidebar-cat-0-en-105":81},{"code":4,"msg":5,"data":6},0,"success",{"doc_id":7,"user_id":8,"nickname":9,"user_avatar":10,"doc_module":4,"category_id":11,"category_name":12,"doc_title":13,"doc_description":14,"doc_content":15,"file_id":16,"file_url":17,"file_type":18,"file_size":19,"view_count":4,"is_deleted":4,"is_public":20,"is_downloadable":20,"audit_status":20,"page_count":21,"language":22,"language_code":23,"site_id":24,"html_lang":23,"table_of_contents":25,"faqs":26,"seo_title":13,"seo_description":14,"update_tm":27,"read_time":28},84543,34359740700684,"Finn","https://ap-avatar.wpscdn.com/avatar/1f400023980c374ae676?_k=1777273430885731487",8,"Research & Report","Promise Future Synchronization for Cluster Asynchronous Many Task Runtimes via MPI One Sided Communication","Asynchronous Many-Task (AMT) runtimes use futures to represent values produced by other tasks. The ItoyoriFBC runtime previously used a future-only model that binds each future to its producer at creation time and fixes the consumer count at compile time, limiting dynamic dependency construction. This work extends ItoyoriFBC with a promise-future model that enables dynamic task graphs, including Hierarchical LU factorization (HLU), and evaluates near-ideal scaling up to 16 nodes.","arXiv :2607 .00303v 1 [ cs .DC] 1 Jul 2026  \nPromise-Future Synchronization for Cluster Asynchronous Many-Task Runtimes via MPI One-Sided Communication  \nMia Reitz  \nUniversity of Kassel, Research Group Programming Languages/Methodologies  \n[mia.reitz@uni-kassel.de](mia.reitz@uni-kassel.de)  \nAbstract. Asynchronous Many-Task (AMT) runtimes use futures as placeholders for values produced by other tasks. In the ItoyoriFBC AMT runtime, the existing future-only model binds each future to its producer at creation time and requires the number of tasks that read each future to be fixed at compile time. This prevents directly expressing algorithms that create dependencies dynamically. We extend ItoyoriFBC with an implementation of a promise-future model that lifts these limitations.  \nThereby, our ItoyoriFBC variant supports dynamic algorithms such as Hierarchical LU factorization (HLU) . We experimentally evaluated our implementation using HLU on up to 16 nodes and observed near-ideal scaling with a 15.6 × speedup.  \nKeywords: Futures · Promises · Work Stealing · Asynchronous ManyTask Programming  \n1 Introduction  \nAsynchronous Many-Task (AMT) runtimes (e.g., HPX and Legion) divide computations into fine-grained tasks and often express dependencies through futures: placeholders for values that producer tasks create and consumer tasks read later. A runtime typically assigns the tasks dynamically to worker processes through work stealing, where idle workers steal tasks from others.  \nItoyori [1] is a cluster AMT runtime combining work stealing with MPIone-sided communication for nested fork-join programs, and ItoyoriFBC extends it with support for futures [2] . The futures in ItoyoriFBC follow a future-only model that binds each future to its producer task during task creation and requires a compile-time fixed consumer count (see Listing 1.1) . The future-only model works when dependencies are known at task creation, but not when tasks discover dependencies dynamically while building the task graph such as in a recent algorithm for the LU factorization of hierarchical matrices (HLU) [3] .  \nThe promise-future model separates the producer side from the consumer side: a promise provides the value, while futures consume it (Listing 1.2) . For example, the recent HLU algorithm requires a parent task to pass futures to child tasks before spawning the corresponding producer tasks.  \n2 M. Reitz  \nRealizing this model in ItoyoriFBC creates two challenges. First, the runtime must know when it is safe to reclaim the memory of task results, even thoughthe number of futures may vary during execution. Second, a consumer task may access a future before the corresponding producer task exists, so the runtime must be able to pause and later resume a variable number of consumers (called waiters) . This work investigates how the promise-future model can be realized in ItoyoriFBC. Our contributions are: (1) a data structure design to handle the two challenges, (2) its implementation in ItoyoriFBC, and (3) an evaluation of our implementation with HLU on up to 16 nodes.  \n1  \n2  \n3  \nListing 1.1 . Future-only Model  \nfuture \u003C int , 1 > f =  \nspawn ([=] { return 42; }); int v = f . get ();  \nListing 1.2 . Promise-Future Model 1  \n2  \n3  \n4  \npromise \u003C int > p = promise \u003C int >:: make (); future \u003C int > f = p . get _ future ();  \nspawn ([ p ] { p . set (42); });  \nint v = f . get ();  \n2 Design  \nAs shown in Figure 1, futures in ItoyoriFBC use a shared state object that stores the produced value and tracks tasks that may access or wait for it. In our extension, each promise and its corresponding futures refer to this shared state (see Figure 3), stored on a home process, i.e., the MPI process responsible for it. The home process creates the promise; ideally, it also accesses the future data, since each access may require MPI one-sided communication.  \nChallenge 1: Reclaiming Shared State Because futures may be created dynamically (e.g., by copying a future), ","cbCaib4rKRhKKvkp","https://ap.wps.com/l/cbCaib4rKRhKKvkp","pdf",429445,1,4,"English","en",105,"# Introduction\n# Design\n## Challenge 1: Reclaiming Shared State\n## Challenge 2: Suspending and Resuming Consumers","[{\"question\":\"What are the two main implementation challenges when realizing promise-future synchronization in ItoyoriFBC?\",\"answer\":\"The runtime must (1) reclaim shared state safely despite dynamically created futures, using reference counting, and (2) suspend and later resume consumer tasks that access a future before its producer exists.\"}]",1784196550,10,{"code":4,"msg":30,"data":31},"ok",{"site_id":24,"language":23,"slug":32,"title":13,"keywords":33,"description":14,"schema_data":34,"social_meta":76,"head_meta":78,"extra_data":80,"updated_unix":27},"promise-future-synchronization-for-cluster-asynchronous-many-task-runtimes-via-mpi-one-sided-communication","",{"@graph":35,"@context":75},[36,52,66],{"@type":37,"itemListElement":38},"BreadcrumbList",[39,43,47,50],{"item":40,"name":41,"@type":42,"position":20},"https://docshare.wps.com","Home","ListItem",{"item":44,"name":45,"@type":42,"position":46},"https://docshare.wps.com/document/","Document",2,{"item":48,"name":12,"@type":42,"position":49},"https://docshare.wps.com/document/research-report/",3,{"item":51,"name":13,"@type":42,"position":21},"https://docshare.wps.com/document/promise-future-synchronization-for-cluster-asynchronous-many-task-runtimes-via-mpi-one-sided-communication/84543/",{"url":51,"name":13,"@type":53,"author":54,"headline":13,"publisher":56,"fileFormat":59,"inLanguage":23,"description":14,"dateModified":60,"datePublished":60,"encodingFormat":59,"isAccessibleForFree":61,"interactionStatistic":62},"DigitalDocument",{"name":9,"@type":55},"Person",{"url":40,"name":57,"@type":58},"DocShare","Organization","application/pdf","2026-07-16",true,{"@type":63,"interactionType":64,"userInteractionCount":4},"InteractionCounter",{"@type":65},"ViewAction",{"@type":67,"mainEntity":68},"FAQPage",[69],{"name":70,"@type":71,"acceptedAnswer":72},"What are the two main implementation challenges when realizing promise-future synchronization in ItoyoriFBC?","Question",{"text":73,"@type":74},"The runtime must (1) reclaim shared state safely despite dynamically created futures, using reference counting, and (2) suspend and later resume consumer tasks that access a future before its producer exists.","Answer","https://schema.org",{"og:url":51,"og:type":77,"og:title":13,"og:site_name":57,"og:description":14},"article",{"robots":79,"canonical":51},"index,follow",{"doc_id":7,"site_id":24},{"code":4,"msg":5,"data":82},[83,87,91,95,100,105,110,113,118,121,124],{"id":20,"doc_module":4,"doc_module_name":45,"category_name":84,"show_sort_weight":85,"slug":86},"Story & Novel",90,"story-novel",{"id":46,"doc_module":4,"doc_module_name":45,"category_name":88,"show_sort_weight":89,"slug":90},"Literature",80,"literature",{"id":21,"doc_module":4,"doc_module_name":45,"category_name":92,"show_sort_weight":93,"slug":94},"Exam",70,"exam",{"id":96,"doc_module":4,"doc_module_name":45,"category_name":97,"show_sort_weight":98,"slug":99},5,"Comic",60,"comic",{"id":101,"doc_module":4,"doc_module_name":45,"category_name":102,"show_sort_weight":103,"slug":104},6,"Technology",50,"technology",{"id":106,"doc_module":4,"doc_module_name":45,"category_name":107,"show_sort_weight":108,"slug":109},7,"Healthcare",40,"healthcare",{"id":11,"doc_module":4,"doc_module_name":45,"category_name":12,"show_sort_weight":111,"slug":112},30,"research-report",{"id":114,"doc_module":4,"doc_module_name":45,"category_name":115,"show_sort_weight":116,"slug":117},9,"Religion & Spirituality",20,"religion-spirituality",{"id":116,"doc_module":4,"doc_module_name":45,"category_name":119,"show_sort_weight":116,"slug":120},"World Cup","world-cup",{"id":28,"doc_module":4,"doc_module_name":45,"category_name":122,"show_sort_weight":28,"slug":123},"Lifestyle","lifestyle",{"id":125,"doc_module":4,"doc_module_name":45,"category_name":126,"show_sort_weight":96,"slug":127},19,"General","general"]