Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4323273

java.util.Date has a synchronization problem when initializing static vars

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      02
    • CPU:
      generic
    • OS:
      generic
    • Verification:
      Verified

      Backports

        Description



        Name: elC94547 Date: 03/20/2000


        JDK 1.2, 1.2.2 and 1.3 class java.util.Date uses the following
        algorithm to maintain many operations like Date.getDay() etc.:

            private final int getField(int field) {
                if (cal == null) {
                    if (staticCal == null)
                        makeStaticCalendars();
                    synchronized (staticCal) {
                        staticCal.setTimeZone(TimeZone.getDefault());
                        staticCal.setTimeInMillis(fastTime);
                        return staticCal.get(field);
                    }
                }
                else {
                    TimeZone defaultZone = TimeZone.getDefault();
                    if (!defaultZone.equals(cal.getTimeZone())) {
                        long ms = cal.getTimeInMillis();
                        cal.setTimeZone(TimeZone.getDefault());
                        cal.setTimeInMillis(ms);
                    }
                    return cal.get(field);
                }
            }

        Here we see, that operations over the 'staticCal' are embraced
        with synchronized (staticCal) {...} section.

        But operations over the 'cal' field are not synchronized; and
        I'm afraid, that this may cause problems when the class Date
        is used by different threads.

        In particular, it looks like poor synchronization in the class
        Date is causing failures of the stress-test:
            nsk/stress/jck12a/jck12a003
        which executes hundreds of JCK 1.2a tests as concurrent threads.
        The method Date.getDay() intermittently produces an incorrect
        result in such executions.

        [ Note, that implementation of the method Date.getDay() is the
          same in JDK 1.2, 1.2.2 and 1.3. ]

        I have observed failures of the method Date.getDay() using the
        following environment:
        - Dual Pentium-II computer, 2x350MHz, 512Mb RAM
        - Windows NT 4.0 Server, SP3, IE4

        To reproduce such failure, please try the script DOIT.BAT in
        the directory:
            /net/sqesvr/vsn/GammaBase/Bugs/<this_bug_number>

        ======================================================================
        Name: elC94547 Date: 03/22/2000



        I'm afraid that the description of this bug report was not enough
        clear. That was my fault -- I'm sorry! Please, let me explain the
        problem in few more details:

        Indeed: if a Date object is shared by multiple threads,
                          ^^^^^^^^^^^^^^^^
        then operations like following ought to be blocked:
          synchronized (d) {
        d.setYear(2000 - 1900);
        d.setMonth(2);
        d.setDay(21);
        t = d.getTime();
        }

        However, the test nsk/stress/jck12a/jck12a003 involve the
        JCK tests:
            lang/PKGS/pkgs015/pkgs01502/pkgs01502.html
            lang/PKGS/pkgs016/pkgs01601/pkgs01601.html
            lang/PKGS/pkgs025/pkgs02501/pkgs02501.html
            lang/PKGS/pkgs027/pkgs02701/pkgs02701.html
            lang/PKGS/pkgs027/pkgs02702/pkgs02702.html
            lang/PKGS/pkgs027/pkgs02703/pkgs02703.html
        which intermittently fail on much simpler checks like e.g.:
            Date d = new Date (96, 6, 10); // July 10,1996
            if ( d.getDay () != 3 ) { // Wednesday
                out.println ( "not pass 2" );
                return 2;
            }
        In these checks, a Date object is NOT shared by multiple threads.
                                ^^^^^^^^^^^^^^^^^^^^

        I'm afraid, that some side effect of manipulating to static
        fileds of the class Date may prevent it from returning correct
        results when this class (not class instance!) is referenced by
        multiple threads.

        So, would you take a look at the failures of the test
        nsk/stress/jck12a/jck12a003 demonstrated by the script DOIT.BAT
        found in the directory /net/sqesvr/vsn/GammaBase/Bugs/4323273,
        please?

        The failures reproduce quite regularily -- approximately in
        3 of 10 executions. So, I believe that those failures still
        need to be investigated.


        ======================================================================

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                okutsu Masayoshi Okutsu
                Reporter:
                elatkinsunw Eugene Latkin (Inactive)
                Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: