Thanks. Adding the global keyword to definition of d works.
Using remoteref also works.
Here is the snippet with remoteref
------------------
function foo()
d = zeros(5)
for i = 1:5
d [i] = i
end
r = RemoteRef()
put!(r, d)
r
end
function bar(r)
d = take!(r)
println ("d", d)
end
function test_parallel()
r1 = @spawnat 2 foo()
r2 = fetch(r1)
@spawnat 2 bar(r2)
end
----------------------
Is there a limit on the number of RemoteRef() calls that can be made in a
given process?
Do 2 RemoteRef() calls in the same process yield 2 different remote
references?
Thanks.
On Wednesday, May 28, 2014 6:19:39 PM UTC-4, Jameson wrote:
>
> Right, but that's where you can return a remoteref wrapper instead of the
> entire array (or perhaps spawnat does this already? I don't recall exactly)
>
> On Wednesday, May 28, 2014, Stefan Karpinski
> <[email protected]<javascript:>>
> wrote:
>
>> I suspect that global variable is what Eka is after here. If you put
>> "global" in front of the definition of d, it will work. I would advise
>> against using globals, however. It's much better to return the array and
>> pass it to the other function as an argument.
>>
>> On May 28, 2014, at 5:24 PM, Jameson Nash <[email protected]> wrote:
>>
>> A RemoteRef lets up pass around a variable without actually moving the
>> data (until you fetch)
>>
>> On Wednesday, May 28, 2014, Eka Palamadai <[email protected]> wrote:
>>
>>> Is it possible to persist a variable across function calls?
>>>
>>> Consider 2 functions foo and bar shown below :
>>> -----------------------------
>>> function foo()
>>> d = zeros(5)
>>> for i = 1:5
>>> d [i] = i
>>> end
>>> end
>>>
>>> function bar()
>>> println ("d", d)
>>> end
>>>
>>> function test_parallel()
>>> @spawnat 2 foo()
>>> @spawnat 2 bar()
>>> end
>>> -----------------------------
>>> The code doesn't compile since d is not defined in function bar.
>>>
>>> foo defines array d but bar needs to use d as well.
>>>
>>> How could both foo and bar use d without passing d around?
>>>
>>> I could pass d back and forth, but i would like to avoid the
>>> communication overhead.
>>> Any ideas?
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
