This is the mail archive of the
java-patches@sourceware.cygnus.com
mailing list for the Java project.
Re: libgcj/38
- To: Tom Tromey <tromey at cygnus dot com>
- Subject: Re: libgcj/38
- From: Bryce McKinlay <bryce at albatross dot co dot nz>
- Date: Fri, 25 Feb 2000 22:18:09 +1300
- CC: java-gnats at sourceware dot cygnus dot com, Java Patch List <java-patches at sourceware dot cygnus dot com>
- References: <20000225085000.28264.qmail@sourceware.cygnus.com> <200002250855.AAA27307@ferrule.cygnus.com>
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 ]