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
|
