2008/7/21 Peter W. Draper <[log in to unmask]>:
> On Fri, 18 Jul 2008, Tim Jenness wrote:
>
>> On Jul 18, 2008, at 8:30 AM, David Berry wrote:
>>
>>> 2008/7/18 Tim Jenness <[log in to unmask]>:
>>> > On Fri, 18 Jul 2008, Peter W. Draper wrote:
>>> > > > - linking against the C SLA is now not possible (I would imagine
>>> > > > that
>>> > C SLA is already thread-safe but I haven't checked for statics).
>>> > Since there are no API changes for the _r I imagine we would be able
>>> > to get away with an include file that uses a macro to turn them into
>>> > normal C SLA versions.
>>>
>>> Not sure I follow. The old wrappers are still available in sla.o, with
>>> the new ones in sla_r.o. Both of these object modules are included in
>>> libsla, so are available for the linker when you use sla_link(_adam).
>>> Code that wants to use a threadsafe sla routine specifies the "_r"
>>> variant in the source code. Code that wants to avoid the overhead of
>>> the threadsafe variant can still specified the original routine name.
>>>
>>> I'm probably missing something here...
>>>
>>
>> The problem is that if you link against Pat's C version of sla instead of
>> the fortran version with the C wrapper it is automatically reentrant. Prior
>> to today a user always had the option of inserting the C version into the
>> tree and building against that. Now they don't have that option.
>>
>> This may be a minor thing but we're extending the SLA C API in a way that
>> is not necessary for the C slalib.
>>
>> #define slaObs_r slaObs
>>
>> in Pat's C slalib.h would fix it but that's not really something that we
>> should need to ask.
>>
>> I realise that we have no choice without slowing down every sla C call
>> with a mutex.
>
> Hmm, not convinced there's a need for any of this. As far as I can see
> SLALIB Fortran doesn't use COMMON blocks or explicitly SAVE'd variables, so
> shouldn't it be perfectly reentrant already?
I thought all Fortran local variables were allocated statically? And
also, the Intel thread checker threw up reports about potential data
races within deuler.f
David
|