It would be extremely useful to have shared arrays of non-bit-types. Automatic differentiation, for example, requires functions to accept <:Real types, and this makes shared arrays difficult to use within function evaluations in an optimization algorithm.
More broadly, is there a technical reason that not all objects are in shared memory by default? I imagine that this is to protect programmers from themselves (trying to modify the same address in memory), but this doesn’t seem necessary if the programmer is careful.
You might be able to use reinterpret, esp. on 0.7, to interpret a bits buffer as something else. Fundamentally the data has to be a contiguous “just bits” array because it’s your OS kernel that’s doing the real work with SharedArrays and in the end it needs a void * pointer to access.
Not really sure what you mean but if you can somehow make sure all the data stored in the array as isbits type then it can work. If there’s any memory reference in the array then it’s impossible
Sorry for my delay in response. To follow up and clarify:
Say, for example, that I want to use automatic differentiation to optimize a complicated statistical model f(data,parameters) with respect to the parameters. Computing f() even once may be expensive and the evaluation of f() can often be broken down into parts that can be computed in parallel. This all works well in theory, except that any subroutines within f() that use parameters must accept dual numbers (<:Real) in order to work with automatic differentiation. SharedArrays only accept bits-types (and therefore cannot accept dual numbers) making SharedArrays difficult if not impossible to use in such cases.
Isn’t your type concrete and bitstype once you have specified the dual number? Otherwise allocations shoot your performance anyway.
And a lot of reference types can often be replaced by an offset into an array (which works fine for shared arrays and often saves you 4 bytes if 32 bit offsets are enough for you; I don’t know how big your arrays are).