[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [igraph] thead-safe arpack

From: Tamas Nepusz
Subject: Re: [igraph] thead-safe arpack
Date: Fri, 8 Oct 2010 10:27:06 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]