On Monday, July 20, 2015 08:19:43 PM John Brock wrote: > Isn't that what DArrays are for, though?
With a DArray, each chunk is local to only one process. That makes it really expensive to read data from other chunks. With SharedArrays, you have fast read access to the whole thing. But you have to be careful with updates. > Does Julia provide a mechanism for > mutual exclusion/marking critical sections? The easiest is to restrict your changes to localindexes(S) > I'm imagining something like: > > > shared_result = SharedArray(Int64, (2,), init = S -> S[localindexes(S)] = 0 > ) > @parallel for i=1:3 > lock shared_result > shared_result[:] += [i, i] > end > end I'm not aware of any implementation of locking, but you should be able to implement it yourself: https://en.wikipedia.org/wiki/Peterson%27s_algorithm and the alternatives linked in "See also". --Tim > > On Monday, July 20, 2015 at 6:59:03 PM UTC-7, Tim Holy wrote: > > Usually the whole point of a SharedArray is that workers only update the > > piece > > they "own." You can make it work different if you implement locking, but > > lock > > contention can be a bottleneck. > > > > --Tim > > > > On Monday, July 20, 2015 04:29:04 PM John Brock wrote: > > > I'm seeing inconsistent results when multiple workers write values to a > > > SharedArray at the same time, presumably because += isn't atomic. Is > > > > this > > > > > intended behavior, and is there a workaround? Behavior is reproducible > > > > in > > > > > 0.3.8-pre+22 and 0.3.9. > > > > > > Sample code: > > > > > > function doStuff() > > > > > > result_shared = SharedArray(Int64, (2,), init = S -> > > > > S[localindexes(S)] = > > > > > 0) > > > > > > @sync for i=1:3 > > > > > > @spawn begin > > > > > > result_shared[:] += [i, i] > > > > > > end > > > > > > end > > > return sdata(result_shared) > > > > > > end > > > > > > > julia -p 3 > > > > > > julia> dump(doStuff()) > > > Array(Int64,(2,)) [3,3] > > > > > > julia> dump(doStuff()) > > > Array(Int64,(2,)) [6,6]
