<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Phil,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thank you for a good question! <span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">I created an issue: https://github.com/pmodels/argobots/issues/287</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<div><br>
</div>
<div>Yes, what you expect is correct. A ULT (lock/unlock) may not yield if there is no contention. We guarantee this and will make it clear in the specification.</div>
<div><br>
</div>
<div>The current Argobots (assuming the current master) should work as you expect; ULT A should never yield in your case.</div>
<div><br>
</div>
<div>In the case of Argobots 1.0 or 1.0.1, a ULT may yield because of the following possible reasons, both of which are fixed in the current master:</div>
<div>1. Lock is not performed atomically "strong" while the architecture supports weak atomics (e.g., on ARM and POWER) (fixed by https://github.com/pmodels/argobots/pull/223)</div>
<div>2. If you explicitly pass `--disable-simple-mutex` at configuration time, the previous mutex-handover mechanism may have this issue (fixed by https://github.com/pmodels/argobots/pull/268)</div>
<div><br>
</div>
<div>Regarding 1., because some atomic instructions spuriously fail ("weak" https://en.cppreference.com/w/c/atomic/atomic_compare_exchange), maybe the current spinlock implementation in Argobots causes this issue if you are using non-Intel hardware. I'd be
happy if you could let us know what combination of hardware and compiler (with a compiler version) you are using. If you are using Intel hardware, I believe the current Argobots master work correctly unless you use a not-so-common compiler (e.g., PGI), but
I will check.</div>
<div><br>
</div>
<div>(Note that a priority lock/unlock is just a hint, so it will not help.)</div>
<div><br>
</div>
<div>Anyway, I should make this point clearer in the specification. At the same time, I will add a test to see if this is really the case. If the current mechanism is broken, I will fix it. Please estimate that this clarification and fix (if possible) will
come this week.</div>
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Shintaro Iwasaki</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Phil Carns via discuss <discuss@lists.argobots.org><br>
<b>Sent:</b> Wednesday, January 6, 2021 12:27 PM<br>
<b>To:</b> discuss@lists.argobots.org <discuss@lists.argobots.org><br>
<b>Cc:</b> Carns, Philip H. <carns@mcs.anl.gov><br>
<b>Subject:</b> [argobots-discuss] question about ABT_mutex and ULT scheduling</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi all,<br>
<br>
We've isolated a situation where the ABT_mutex construct is behaving a <br>
little differently than I expected. We have two ULTs running on a <br>
single ES. The ULTs are using ABT_mutex_lock/free() to protect a shared <br>
data structure. This specific configuration will never have lock <br>
contention (the mutex is really there to protect more complex <br>
configurations where there are more ESs and ULTs participating than what <br>
I described above).<br>
<br>
Here is what puzzles me: I'm not 100% sure, but it really looks like ULT <br>
A yields to ULT B when attempting to lock the mutex sometimes, even <br>
though there is no contention.<br>
<br>
This is a performance bug for us; ULT B is only supposed to execute when <br>
ULT A is idle in this configuration. We don't really want to give up <br>
execution when acquiring an uncontested mutex if we don't have to.<br>
<br>
I'm sure we could work around it (restructuring our code, or using a <br>
spinlock or priority mutex or something), but I wanted to ask on the <br>
list first: is the behavior I described above (a ULT yielding on a mutex <br>
lock, even if the mutex is available) expected? Or is it an indication <br>
that we are doing something wrong somewhere? I want to make sure that I <br>
understand the problem before altering the code.<br>
<br>
thanks!<br>
<br>
-Phil<br>
<br>
<br>
_______________________________________________<br>
discuss mailing list<br>
discuss@lists.argobots.org<br>
<a href="https://lists.argobots.org/mailman/listinfo/discuss">https://lists.argobots.org/mailman/listinfo/discuss</a><br>
</div>
</span></font></div>
</body>
</html>