Re: Parallel access to data created with Octave

[Jarno Rajahalme]

On May 3, 2010, at 8:14 AM, ext Jaroslav Hajek wrote:
> 
> The problem is that your code may stop working essentially any time
> because of internal changes, and it may be hard to figure out what is
> wrong. For instance, in Octave 3.3+, a double real value with
> is_scalar_type() = true is *not* necessarily an octave_scalar
> instance.
> 

Thanks for the note. However, in this case I'm extracting values from a 
structure that I have created myself. I know I could add a couple of checks 
(outside of the loops) to make sure the structure seems to contain only 
uint16's (either arrays or scalars).

For the case where I test for scalar type, it would suffice if numel() on a 
scalar would not depend on a static initialization of a "static dim_vector 
dv(1,1); return dv;" within a function dims(). If octave_base_scalar 
implemented a numel() always returning 1, I would not have to care whether a 
specific cell is a scalar or not. And it would be faster, too :-).

> I would suggest you try to hoist as much of the value extraction calls
> as possible out of the parallelized loops. If it's not possible, you
> can use #pragma omp critical. Perhaps the pragmas will be inserted in
> Octave's sources in the future.
> 

In this case doing this would effectively mean copying a multi-megabyte 
structure from Octave to C, and is not an option, at least for now. I could add 
a separate initialization function to that effect, but then I would have to 
worry about calling that each time the Octave structure is changed to keep them 
in sync.

Declaring value extraction functions critical would unnecessarily slow down the 
code. IMO, just inspecting data should not do anything that would not work when 
parallel. I guess there are NOT that many places where things break down. Maybe 
one issue is with the reference counts being incremented and decremented, when 
extracting values, and every now and then there will be a race regarding a 
reference count: 2 threads read the same value, increment it and then 
independently decrement it, causing the data to be freed. This could be solved 
by making reference count manipulation critical, or by enabling data inspection 
without touching the reference values at all (as I have now done).

  Jarno