On Fri, 25 Apr 2008, Peter W. Draper wrote:
> On Fri, 25 Apr 2008, Malcolm J. Currie wrote:
>
>>> Rewriting everything is about the only thing that can be done. NDF is a
>>> big problem (fortran). AST is another (globals). HDS uses hds_gl_status
>>> *everywhere* (presumably because it was simple) and that has to go. EMS is
>>> not thread-safe (the error stack is a big global and is clearly a
>>> problem with threads).
>
> While all this is true in general and it would be nice to sort out, is it a
> specific problem? In Java (never done any thread programming in C), you could
> just use threads in the parts of the program that require it, in this case
> once you'd gotten hold of the data from NDF, don't query it again or use EMS
> until the serious processing is complete.
>
It is a problem when you have a nicely working program and you suddenly
realise that you can't use EMS, AST, KAPLIBS or HDS inside any of the
loops that you are about to thread.
Ed Chapin spent a lot of effort moving all the starlink code out of the
iterative loops in the scuba-2 map maker in smurf but we still really
really want to use AST occassionally (we can't even use an astKeyMap)
and we are forced to use GSL or FFTW rather than kaplibs routines. He
ended up writing his own routines for writing memory mapped binary files
(temporary files created during the looping to reduce memory).
AST is the big one but you essentially train yourself out of using any
Starlink software when coding up algorithms that might need to be
threaded.
I realise that starting to rewrite the fortran in C is not tenable. What
annoys me is the way that the code that has already been ported to C is
riddled with global variables.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|