I understand *why* you're using them; the question is whether they're broken or not. One way to figure that out is to not use them and see if you still get the weird behavior.
(No worries on the response speed, this is your issue after all!) On Wednesday, April 8, 2015 at 7:57:54 AM UTC-5, Nils Gudat wrote: > > Hi Patrick, > > Sorry for the late reply (Easter and all that)! The problem with using > Arrays in the code above is that they're not available for remote processes > to write on, so I'd have to come up with a more complicated structure of > passing computations and results around. The whole appeal of SharedArrays > to me is that they make this unnecessary and therefore lend itself > perfectly to facilitate easy parallelization of the kind of problems > economists are often facing (basically filling large Arrays with the > results of lots and lots of simple maximization problems). One way to get > around both problems would be to initialize the Array as > > nprocs() > 1 ? result1 = SharedArray(Float64, (3,3,3)) : result1 = > Array(Float64, (3,3,3)) > > The main reason for my original post here was to see whether anyone could > explain why SharedArrays behave in this way when used on one process and > whether this was potentially a bug (or at least something that should be > mentioned in the docs). >
