Re: [Lapackpp-devel] thread safety of lapack++

[Christian S. <sti...@tu...>]

Am Samstag, 1. Dezember 2007 07:49 schrieb Matt Hansen:
> I've noticed that some of the functions in lapack++ do not appear to
> be thread safe, which is inconvenient when programming for new
> multi-core processors, although not impossible to work around. I was
> wondering if anyone has a comprehensive list of which functions are
> not thread safe.

I'm curious what you mean by "not thread-safe". 

Are you talking about static class variables? Those exist, but are limited to 
debugging output and formatting of that output - they don't affect any normal 
computations.

Or are you talking about locking access to the object content? Then I have to 
disappoint you - the access methods of all matrix classes do *not* include 
any form of thread synchronization (i.e. an access mutex). This is 
intentional and it will stay this way, because introducing thread 
synchronization at the level of the matrix classes is the wrong level of 
dealing with this. Imagine a "thread-safe matrix class": It would have to 
contain a mutex, which on each operator()(int,int) access will get locked, 
the element will be returned, and the mutex will be unlocked. Now imagine 
someone using the operator()(int,int) in a for-loop. You will have O(n^2) 
mutex locking/unlocking in that loop, which is just insane. (Similar 
arguments explain why std::vector<> is not "thread-safe" and never should 
be.)

No, dealing with thread synchronization has to be done on a higher layer, i.e. 
outside of Lapackpp. In that sense, all Lapackpp's classes and functions are 
indeed not "thread-safe".

Christian

> I'm currently using the following functions and data structures in my code:
> LaGenMatDouble
> LaGenMatComplex
> LaVectorDouble
> LaVectorComplex
> LaVectorLongInt
>
> LaEigSolve
> Blas_Mat_Mat_Mult
> LuFactorizeIP
> LaLUInverseIP
>
> Thank you in advance for any insight you can offer,
>
> Matt Hansen
> Electrical Engineering and Physics at MTU