This is the mail archive of the java-patches@sourceware.cygnus.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: libgcj/38


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 ]




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]