Hi Marcin --
I believe that, at present, the answer to this depends on the type of
domain. IIRC, dense rectangular domains don't have any task-safety built
into them at present. However, I believe that sparse and associative
domains do support having multiple tasks add indices to them
simultaneously, and that the locking is done automatically under the
covers. If we've done the distributed versions correctly, this should
only do locking on the local data structures.
I believe that there's a way to disable this safe(r)-by-default behavior
for sparse and associative domains, but don't recall that there's a way to
opt into it for dense domains at present.
I should note that not everything you might do is safe for the sparse /
associative cases. For example, changing the domain while another task is
iterating over the domain or array is not protected at all and is likely
to cause problems.
Hopefully others will correct me if I'm misremembering anything.
-Brad
On Tue, 3 Apr 2018, Zalewski, Marcin J wrote:
I have a follow up question. I assume that changing a domain of an
array, distributed or not, is not a thread safe operation, right? So I
would need to synchronize it? The way to do that that I gathered from
the existing codes is to use a sync variable. So, currently, my plan is
to have a bool sync variable to lock the code around domain
modifications. I imagine that this will be pretty slow in a distributed
mode, but domain modifications should not be too frequent in my current
use case.
Thank you,
Marcin
On 4/2/18, 5:00 PM, "Brad Chamberlain" <[email protected]> wrote:
Hi Marcin --
> Yes, that is a very good idea. I did wonder where to best ask this
> question, and you are right that Stack Overflow looks like the best
> option
It's definitely fine to ask them here as well (and it allowed me to be a
bit more complete in my answer). But SO is good to keep in mind as an
option.
> That's exactly what I needed! Cyclic and BlockCyclic fit my need very
> well. I just went for Block, but now that I think about it, I should
> definitely started with Cyclic. I think I got thrown off by so many
> examples in the test directory using Block, and I thought that if Block
> implemented something so would Cyclic, if maybe at different cost. Your
> answer clarifies that this is not the case.
Yeah, Block is such a common case (and for us tends to be the most studied
and optimized case) that it tends to show up disproportionately in code
and documentation. (Which is ironic given that Cyclic is strictly simpler
to understand and parameterize....)
> If index locality doesn't matter to you at all, another option to
explore
> would be to use a distributed associative domain. This results in even
> ...
>
> When you say it did not make it to master, do you mean that currently
> this feature is not publically available anywhere?
I believe we have a prototype in our test/ directory, though the latest
version of it may be on a developer branch that hasn't been merged. Let
me check on that and have one of us get back to you. It's kind of
ridiculous how long it's lived in limbo, 90% done (where I can say that
because I'm responsible for most of that delay).
> Yes, exactly. You are correct; Block is not necessary. Cyclic is
> actually much better for some algorithms anyway, at least for naïve
> implementations. Also, with Cyclic I do not need to worry as much about
> having my graph balanced in the first place. For example it would be OK
> if lower indices had larger neighbor lists, while with Blocked I would
> need to make sure I got the distribution of degrees right, or I would be
> in trouble immediately.
True!
> Yes, this was a great answer that gave me all the tools I need to go
> forward. Thank you again. (
You're very welcome.
-Brad
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
