libgcj/38

[Bryce McKinlay]

The following reply was made to PR libgcj/38; it has been noted by GNATS.

From: Bryce McKinlay <bryce@albatross.co.nz>
To: Tom Tromey <tromey@cygnus.com>
Cc: java-gnats@sourceware.cygnus.com,
        Java Patch List <java-patches@sourceware.cygnus.com>
Subject: Re: libgcj/38
Date: Fri, 25 Feb 2000 22:18:09 +1300

 Tom Tromey wrote:
 
 > Bryce>  Well now that you point this out, it will have to synchronize
 > Bryce>  around the "locale == null" check in getHeaderDateField()
 > Bryce>  too. Bummer.
 >
 > Actually, you don't.  Just have redundant checks.  The outer check (in
 > getHeaderDateField) doesn't have to be synchronized, because we do a
 > properly synchronized in the init function.
 >
 > We use this same idiom elsewhere in libgcj.  This gives good
 > performance in the common case (no sync needed), but is also
 > guaranteed to be correct.
 
 Hmm... I don't think that is 100% safe in this case. ie:
 
 Thread A reaches the null locale check in getHeaderDateField(), and calls
 initializeDateFields() which is synchronized. It finishes initializing
 the 'locale' field before the kernel switches context to Thread B, which
 is sitting just before the null locale check. Thread B sees that locale
 is not null, and so tries, unsynchronized, to access 'dateFormat1'.
 NullPointerException.
 
 But I understand what your getting at. The right solution is to use a
 boolean instead, which gets set after the dateFormal fields have all been
 set. Right?
 
 regards
 
   [ bryce ]