<div dir="ltr">If the number of capabilities is increased or decreased while everything I have here is running I'm going to have to blow up the world anyways.<div><br></div><div>Basically I'll need to rely on an invariant that setNumCapabilities is called before you spin up these Par-like computations.<br><div><br></div><div>-Edward</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 28, 2015 at 4:28 PM, Ryan Yates <span dir="ltr"><<a href="mailto:fryguybob@gmail.com" target="_blank">fryguybob@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">A thread with TSO_LOCKED can be migrated if the number of capabilities decreases.<div><br></div><div>Ryan</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Oct 27, 2015 at 11:35 PM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Would anything go wrong with a thread id if I pinned it to a capability after the fact? <div><br></div><div>I could in theory do so just by setting<div><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:12px;line-height:16.8px;white-space:pre-wrap"><br></span></div><div><span style="color:rgb(51,51,51);font-size:12px;line-height:16.8px;white-space:pre-wrap"><font face="monospace, monospace">tso->flags |= TSO_LOCKED</font></span></div><div><font color="#333333" face="monospace, monospace"><span style="font-size:12px;line-height:16.8px;white-space:pre-wrap"><br></span></font></div><div>and then disabling this later by restoring the TSO flags.</div><div><font><br></font></div><div><font>I can't think of anything but I figured folks here might be able to think of invariants I don't know about.<br></font><div><br></div><div>Usage scenario:</div><div><br></div><div>I have a number of things where I can't afford a map from a ThreadId# or even its internal id to a per-thread value for bounded wait-free structures. </div><div><br></div><div>On the other hand, I can afford one entry per capability and to make a handful of primitives that can't be preempted, letting me use normal writes, not even a CAS, to update the capability-local variable in a primitive (indexing into an array of size based on the number of capabilities). This lets me bound the amount of "helpers" to consider by the capability count rather than the potentially much larger and much more variable number of live threads.</div><div><br></div><div>However, I may need to access this stuff in "pure" code that wasn't written with my needs in mind, so I need to at least temporarily pin the current thread to a fixed capability for the duration when that happens.</div></div></div><div><br></div><div>This isn't perfect, it won't react to a growing number of capabilities nicely in the future, but it does handle a lot of things I can't do now at all without downgrading to lock-free and starving a lot of computations, so I'm hoping the answer is "it all works". =)</div><span><font color="#888888"><div><br></div><div>-Edward</div></font></span></div>
<br></div></div>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>