[PATCH] (almost) thread-safe libgfortran

[Steve Kargl]

On Thu, Oct 06, 2005 at 07:53:30PM -0400, Jakub Jelinek wrote:
> 
> Attached you can find my latest version of the patch.
> libgfortran should be almost thread-safe with it.

Cool.

> 2) saved_string/saved_length/saved_used in list_read.c - although
> I have solved this by allocating a scratch buffer, it would be much better
> if I understood what exactly are these 3 supposed to be used for.
> E.g. the
>       saved_length = 2 * saved_length;
>       new = get_mem (2 * saved_length);
>       memset (new,0,2 * saved_length);
>       memcpy (new, saved_string, saved_used);
> is certainly at least weird (why is the buffer always twice saved_length
> except initially, when it is saved_length long, is it really necessary
> to always clear whole second half of the buffer (e.g. wouldn't it be
> sufficient to just make sure it is always zero terminated)?

Many months ago, I looked at the 2 * saved_length and also
thought that it was weird.  I tried changing the buffering
to not waste as much memory, but my attempts led to memory
corruption.  I moved on to changing gfortran to use GMP/MPFR
and forgot about this wart.

> 3) it is not clear to me whether rand/irand/srand/random/arandom/random_seed
> must be thread-safe or not.  OpenMP 2.5 is not very clear on what exactly
> needs to be thread-safe and what doesn't.  If yes, rand.c/random.c will
> need either locking, or __sync_compare_and_swap.

If multiple threads are updating the internal state of the
PRNG, I suspect you'll still get random numbers.  I don't
know if this will effect the quality of the randomness.  The
only problem I can see is the possibility of repeated runs
of a Monte Carlo simulation may not be able to regenerate the
same set of random numbers if there are race conditions.

> 4) similarly system_clock.  tp0 is not accessed in a thread-safe way there,
> but I'd like to hear rationale why it has to be subtracted, why can't
> system_clock simply start with the current time.

Technically, we can remove the tp0.  The Standard does not 
require system_clock to start from zero.  It says

    COUNT (optional) shall be scalar and of type default integer.
    It is an INTENT (OUT) argument.  It is assigned a processor-dependent
    value based on the current value of the processor clock or HUGE(0)
    if there is no clock.  The processor-dependent value is incremented
    by one for each clock count until the value COUNT_MAX is reached and
    is reset to zero at the next count.  It lies in the range 0 to COUNT_MAX
    if there is a clock.

BTW, I noticed the Copyright year in system_clock.c is 2004.
I haven't read through your patch, yet.  But, I thought I 
might as well mention we need to update Copyright years on
files you.

-- 
Steve