 |
 |
On Mon, 21 Jul 2008, David Berry wrote: >> Just a thought in passing. I wonder if declaring Fortran routines to be >> RECURSIVE is actually the right thing to do, that must certainly guarantee >> that multiple instances of the same function can work concurrently. > That's exactly what we want but I'm not sure how portable it is. I know that the Sun compiler supports such a flag because I wrote a recursive routine in SURF on the Sun before someone pointed out that g77 did not work with it at the time. If we went down this road and had a multi-threaded application that relied on reentrant fortran, that application would have to disable threads if it knew that the fortran compiler did not support it. > And another thought that came to me whilst doing the holiday > packing... I wonder if CNF is the cause of the SLA data race problems? > The C wrapper for sla_deuler (and many other wrappers) use CNF to > allocate memory that is then passed to the fortran sla routine as an Well, one thing to try is to use the obfuscated C routines instead for the limited number of sla routines used in SMURF. Or even call the AST pal version. > array argument. Now I presume CNF is not thread safe, so it could be > possible for the allocation of integer identifiers for each malloced > memory block to go up the spout. Could it be possible that the same > integer identifier is being issued for different memory blocks? Or > maybe the other way round - different integer identifiers being > associated with the same memory block? That is a possibility I think because even though the CNF integer corresponding to the C pointer is unique to the pointer (it uses some bit masking) the array it is stored in in CNF is not protected by a mutex so it could be that two routines are trying to store different pointers into the same slot. I can't really remember how it all worked but it might need tweaking. Since David is on holiday now, would it be possible for Peter to take a quick look at CNF? -- Tim Jenness JAC software http://www.jach.hawaii.edu/~timj