- discuss - mailman3.cels.anl.gov

Announcing the release of Argobots 1.1rc1
by Iwasaki, Shintaro 15 Mar '21

15 Mar '21

Dear Argobots Users and Developers, A new preview release of 1.1rc1 is now available for download. Argobots 1.1rc1 fixed several bugs found by Coverity and a new resource leak testing suite that focuses on error handling paths. Argobots synchronization operations on external threads (=Pthreads) are enhanced by futex. You can find the release on our downloads page (https://www.argobots.org/downloads/) If no significant issues are found, we will release Argobots 1.1 this month. If you find any issues or have any feature requests, please let us know by creating a GitHub issue. We thank all the Argobots users and developers for supporting us. Best Regards, The Argobots team

1 0

Re: [argobots-discuss] Announcing the release of Argobots 1.1b1
by Lombardi, Johann 18 Feb '21

18 Feb '21

Thanks Shintaro. Could you please advise what is the expected timeline for 1.1? Cheers, Johann From: "Iwasaki, Shintaro via discuss" <discuss(a)lists.argobots.org> Reply-To: "discuss(a)lists.argobots.org" <discuss(a)lists.argobots.org> Date: Friday 12 February 2021 at 18:23 To: "discuss(a)argobots.org" <discuss(a)argobots.org>, "announce(a)argobots.org" <announce(a)argobots.org> Cc: "Iwasaki, Shintaro" <siwasaki(a)anl.gov> Subject: [argobots-discuss] Announcing the release of Argobots 1.1b1 Dear Argobots Users and Developers, A new preview release of 1.1b1 is now available for download (https://github.com/pmodels/argobots/releases) Argobots 1.1b1 contains several bug fixes and improvements including the API specification clarification and static initializers for ABT_mutex and ABT_cond. The latest API can be found at https://www.argobots.org/doxygen/latest/modules.html We will continue to enrich the Argobots documentation. You can find the release on our downloads page (https://www.argobots.org/downloads/) If you find any issues or have any feature requests, please let us know by creating a GitHub issue. We thank all the Argobots users and developers for supporting us. Best Regards, The Argobots team --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 1

Announcing the release of Argobots 1.1b1
by Iwasaki, Shintaro 12 Feb '21

12 Feb '21

Dear Argobots Users and Developers, A new preview release of 1.1b1 is now available for download (https://github.com/pmodels/argobots/releases) Argobots 1.1b1 contains several bug fixes and improvements including the API specification clarification and static initializers for ABT_mutex and ABT_cond. The latest API can be found at https://www.argobots.org/doxygen/latest/modules.html We will continue to enrich the Argobots documentation. You can find the release on our downloads page (https://www.argobots.org/downloads/) If you find any issues or have any feature requests, please let us know by creating a GitHub issue. We thank all the Argobots users and developers for supporting us. Best Regards, The Argobots team

1 0

question about ABT_mutex and ULT scheduling
by Phil Carns 11 Jan '21

11 Jan '21

Hi all, We've isolated a situation where the ABT_mutex construct is behaving a little differently than I expected. We have two ULTs running on a single ES. The ULTs are using ABT_mutex_lock/free() to protect a shared data structure. This specific configuration will never have lock contention (the mutex is really there to protect more complex configurations where there are more ESs and ULTs participating than what I described above). Here is what puzzles me: I'm not 100% sure, but it really looks like ULT A yields to ULT B when attempting to lock the mutex sometimes, even though there is no contention. This is a performance bug for us; ULT B is only supposed to execute when ULT A is idle in this configuration. We don't really want to give up execution when acquiring an uncontested mutex if we don't have to. I'm sure we could work around it (restructuring our code, or using a spinlock or priority mutex or something), but I wanted to ask on the list first: is the behavior I described above (a ULT yielding on a mutex lock, even if the mutex is available) expected? Or is it an indication that we are doing something wrong somewhere? I want to make sure that I understand the problem before altering the code. thanks! -Phil

2 4

Announcing the release of Argobots v1.0.1 and v1.1a1
by Iwasaki, Shintaro 07 Oct '20

07 Oct '20

Dear Argobots Users and Developers, A new stable release Argobots v1.0.1 and a new preview release of v1.1a1 are now available for download. Argobots 1.0.1 includes a minor bug fix of the ABI string for the Argobots 1.0.x series. Argobots 1.1a1 contains several bug fixes and improvements including a profiler implementation, ABT_key (ULT-local storage) improvements, memory management enhancements, and official support for XLC, PGI, Solaris, and ARM HPC compilers. You can find the release on our downloads page (https://www.argobots.org/downloads/) We would also like to announce that Argobots has been chosen as a finalist for the 2020 R&D 100 Awards. We thank all the Argobots users and developers for supporting us! Best Regards, The Argobots team

1 0

compatibility with ASAN?
by Carns, Philip H. 26 Aug '20

26 Aug '20

Are applications built with argobots expected to work correctly with GCC's AddressSanitizer? I just noticed that asan is used in the automated builds (because it was mentioned in a github ticket), but I did not realize that was a possibility. thanks! -Phil

2 2

API was updated for better error handling
by Iwasaki, Shintaro 22 Aug '20

22 Aug '20

Dear All, For better error handling, we updated returned error codes of Argobots functions (see https://github.com/pmodels/argobots/pull/232) In summary, most of the Argobots functions are classified into one of the three types: 1. A function that can be called by a ULT, a tasklet, or an external thread (e.g., Pthreads) For example, ABT_thread_get_state(ABT_thread thread) can be called by any of them. 2. A function that can be called by a ULT or a tasklet, but not by an external thread For example, an external thread may not call ABT_key_set(). 3. A function that can be called only by a ULT For example, only ULT can yield (ABT_thread_yield()) There exist two exceptions (ABT_task_self() and ABT_task_self_id()), but they will be updated somehow in the future. This update significantly could simplify the current execution contexts implicitly assumed by Argobots functions. >>IMPORTANT<< This change, however, broke the existing API in terms of error codes. Your program might not work if the algorithm relies on the returned error code. https://github.com/pmodels/argobots/pull/232 summarizes all the updated functions. Though this should not affect the core functionality of Argobots, please let us know if your program is broken by this update so that we can fix it. Have a good weekend! Best, Shintaro Iwasaki

1 0

ABT_thread_yield_to() semantics when crossing pools
by Carns, Philip H. 13 Aug '20

13 Aug '20

Hi, I was just curious: what happens if you create a thread on a separate pool (with it's own execution streams) and then call ABT_thread_yield_to()? Nothing? Error? Or maybe it pulls the ULT back to the local execution stream? thanks! -Phil

2 4

scheduling with priority for resumed ULTs
by Carns, Philip H. 13 Aug '20

13 Aug '20

Hi all, I thought this question may be of general interest so I am asking on the mailing list. My understanding is that the default pool/scheduler combination uses FIFO ordering. Suppose we wanted to try a slight variation: FIFO ordering, but with resumed ULTs always taking priority over new ULTs that have not yet begun execution. The use case for this would be for a data service to expedite requests that are already in progress (and were suspended while waiting on disk or network activity) to try to get them out of the system before starting to process new requests, assuming that there is work available in either category. We create a new ULT for every incoming request. Under heavy client process load it is plausible that the final step(s) of servicing an existing request could be delayed behind newly incoming requests, but we haven't empirically confirmed yet. What would be the easiest way to accomplish this? I think I can find a way to do it, but it probably would not be the cleverest solution 🙂 FWIW we usually use ABT_POOL_FIFO_WAIT and ABT_SCHED_BASIC_WAIT rather than the default pool and scheduler, but I don't think that should change anything. They are based on the default pool and scheduler and only differ in terms of their idle behavior. thanks! -Phil

2 9

Argobots 1.0 released
by Iwasaki, Shintaro 31 Mar '20

31 Mar '20

Dear All, We are excited to inform you that we finally released Argobots 1.0, the first stable release of Argobots! https://github.com/pmodels/argobots/releases/tag/v1.0 It contains several bugs fixes in 1.0rc series. Argobots 1.0 has been tested with several compilers (GCC, Clang, Intel, and XLC) on several architectures including x86/64, 64-bit ARM, and POWER. Argobots is being actively developed. We are happy to hear any comments and feedback from you for improving Argobots. Please feel free to ask any questions via this mailing list. Bug reports and pull requests are always welcome. We hope you and your family are safe and well. Best Regards, Shintaro Iwasaki

1 0