Re: [igraph] thead-safe arpack

[Gábor Csárdi]

Matt, Tamas,

I just want to add, that you can also use an external
BLAS/LAPACK/ARPACK library, although we don't test this.

You can set up an error handler that kills the program when an error
happens, so you don't have the unpredictable behavior when a thread
starts deallocating the memory of other threads.

Actually, I am in the process of rewriting the BLAS/LAPACK/ARPACK code
in igraph, because ARPACK fails way too many times for non-symmetric
matrices (and sometimes also for symmetric ones). I am not yet sure
how this will affect (non-)thread-safe behavior.

Best,
Gabor

On Fri, Oct 8, 2010 at 11:27 AM, Tamas Nepusz <address@hidden> wrote:
> Hi Matt,
>
>> The C translation of Arpack is not thread-safe - it uses static
>> variables in many places. Is there any plan to make a thread-safe
>> version of this - so that eigen calculations in igraph can be
>> thread-safe?
> The C translation was made by f2c, so whatever static variables are
> there, those were either there in the original Fortran version, or have
> been introduced by f2c for reasons unknown to me (I'm not too familiar
> with Fortran). The only reason why we ship BLAS/LAPACK/ARPACK in a
> translated C form with igraph is that it makes things easier on Windows
> where it's much harder for the end user to install a Fortran compiler
> than to install a C compiler.
>
> I went through the code and many of the static declarations seem
> spurious to me. It seems like all the local variables are automatically
> declared static, but only a few of them (e.g., inits in igraphdgetv0_)
> represent state information that is kept between calls, so I guess it
> wouldn't be too complicated to clean up the translated C code in order
> to make it thread-safe. That particular example (inits in igraphdgetv0_)
> is used only to keep track of whether the internal random number
> generator of ARPACK was initialised or not, so I guess it's easy to get
> rid of that. But consider that:
>
> 1) the user might want to link to the ARPACK version provided with the
> operating system (e.g., in Linux), and that implementation does not seem
> to be thread-safe either.
>
> 2) the error handling routines in igraph are also not thread safe. There
> is a global stack in igraph where the memory addresses of blocks to be
> freed in case of an error are pushed. This stack is rolled back by the
> igraph error handler, so if an error happens in one of the threads, this
> will roll back the entire stack, including the memory blocks allocated
> by other threads. I guess that one could try and make this thread-safe
> by specifying thread-local storage to the stack in gcc using "__thread"
> and in MSVC using "__declspec(thread)", but we haven't tried that so
> far.
>
> So, the short answer is: no, there are no plans to make ARPACK
> thread-safe in igraph because other parts of igraph are not thread-safe
> either. However, if you happen to do that, you are more than welcome to
> submit a patch.
>
> Cheers,
> Tamas
>
> _______________________________________________
> igraph-help mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/igraph-help
>



-- 
Gabor Csardi <address@hidden>     UNIL DGM