Ticket #6481 (new defect)

Bug contains 1 commit(s) | SVN Diffs for #6481

 

Opened 1 month ago

Last modified 4 weeks ago

Calendar Initialization Thread Safety

Reported by: andy Assigned to: andy
Priority: major Milestone: 4.1.1
Component: time_calc Version:
Keywords: Cc:
Load: Xref:
Java Version: Operating System:
Project (C/J): ICU4C Weeks:
Review: markus

Description

All of our calendar classes use similar lazy initialization for Default Century and Default Year. The initialization is not safe - the check for init involves two variables, and could incorrectly indicate that initialization is complete when it is only partially complete. 

    UBool needsUpdate;
    UMTX_CHECK(NULL, 
               (fgSystemDefaultCenturyStart == fgSystemDefaultCentury),
               needsUpdate);
  • buddhcal.cpp
  • chnsecal.cpp
  • coptccal.cpp
  • ethpccal.cpp
  • gregocal.cpp
  • hebrwcal.cpp
  • islamcal.cpp
  • persncal.cpp
  • taiwncal.cpp

Attachments

Change History

08/04/08 18:09:22 changed by andy

  • status changed from new to closed.
  • resolution set to invalid.

I take it all back.

The existing code is correct, just confusing fgSystemDefaultCentury and fgSystemDefaultCenturyYear really ought to named in some way that shows that they are actually CONST

08/05/08 15:17:46 changed by andy

  • status changed from closed to reopened.
  • project changed from all to ICU4C.
  • component changed from unknown to time_calc.
  • priority changed from assess to major.
  • milestone changed from UNSCH to 4.1.1.
  • resolution deleted.
  • revw set to markus.

Well, looking at it again, the init code does need fixing, so that the variable that flags that initialization has happened is the last assigned during the initialization.

And, there is an additional threading problem with the first "if" statement in most of the initializeSystemDefaultCentury() functions, occuring with processors where memory writes can be reordered (weak memory model, not X86). This 'if' may see the calendar variables in an inconsistent state. The test would need to be inside the mutex, or alternatively, it could just be removed altogether.

08/13/08 11:42:07 changed by srl

  • owner changed from somebody to andy.
  • status changed from reopened to new.

Add/Change #6481 (Calendar Initialization Thread Safety)




Anti spam check: