c - Is ARPACK thread-safe? -
is safe use arpack eigensolver different threads @ same time program written in c? or, if arpack not thread-safe, there api-compatible thread-safe implementation out there? quick google search didn't turn useful, given fact arpack used heavily in large scientific calculations, i'd find highly surprising first 1 needs thread-safe sparse eigensolver.
i'm not familiar fortran, translated arpack source code c using f2c
, , seems there quite few static variables. basically, local variables in translated routines seem static, implying library not thread-safe.
fortran 77 not support recursion, , hence standard conforming compiler can allocate variables in data section of program; in principle, neither stack nor heap needed [1].
it might f2c doing, , if so, might it's f2c step makes program non thread-safe, rather program itself. of course, others have mentioned, check out common blocks well. edit: also, check explicit save directives. save means value of variable should retained between subsequent invocations of procedure, similar static in c. now, allocating procedure local data in data section makes variables implicitly save, , unfortunately, there lot of old code assumes though it's not guaranteed fortran standard. such code, obviously, not thread-safe. wrt. arpack specifically, can't promise arpack regarded , used i'd surprised if suffered these kinds of dusty-deck problems.
most modern fortran compilers use stack allocation. might have better luck compiling arpack with, say, gfortran , -frecursive option.
edit:
[1] not because it's more efficient, because fortran designed before stacks , heaps invented, , reason standards committee wanted retain option implement fortran on hardware neither stack nor heap support way fortran 90. actually, i'd guess stacks more efficient on todays heavily cache-dependent hardware rather accessing procedure local data spread on data section.
Comments
Post a Comment