On Tue, Sep 15, 2015 at 12:29 PM, Mark Thomas <ma...@apache.org> wrote:
> On 15/09/2015 17:59, Yilong Li wrote:
> > On Tue, Sep 15, 2015 at 7:19 AM, Mark Thomas <ma...@apache.org> wrote:
>
> >> Long experience has lead us to be sceptical of bugs reported by
> >> automated tools. When looking at such bugs and we can't see what the
> >> problem is and the person raising the bug can't provide a clear
> >> explanation - and continues not to provide a clear explanation when
> >> asked for one several times - then that is the point where we start to
> >> think the problem is with the tool.
> >>
> >
> > Sorry, I should not assume that the concepts such as happens-before order
> > and memory model are well understood. Let's talk about how this is
> allowed
> > to happen under JMM. Consider the this example again:
> >
> > if (st_200 == null ) {
> > st_200 = sm.getString("sc.200");
> > }
> > return st_200;
> >
> > The following is a valid execution trace consists of 5 events:
> > T1 T2
> > 1 READ null
> > 2 WRITE s
> > 3 READ s
> > 4 READ ???
> > 5 READ s
> >
> > , where s is the result of sm.getString("sc.200").
> >
> > T1 sees null in field st_200, initializes it, and return the initialized
> > value, while T2 sees a non-null value in st_200 and skips the
> > initialization. The question is what value T2 can read and then return in
> > event 4. This is addressed in JLS $17.4.5 Happens-before Order (
> > https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.4.5
> ):
> >
> > We say that a read *r* of a variable *v* is allowed to observe a write
> *w*
> > to *v* if, in the *happens-before* partial order of the execution trace:
> >
> > -
> >
> > *r* is not ordered before *w* (i.e., it is not the case that *hb(r,
> w)*),
> > and
> > -
> >
> > there is no intervening write *w*' to *v* (i.e. no write *w*' to *v*
> such
> > that *hb(w, w')* and *hb(w', r)*).
> >
> > Informally, a read *r* is allowed to see the result of a write *w* if
> there
> > is no *happens-before* ordering to prevent that read.
> >
> > The question boils down to: does the write in event 2 prevent event 4
> from
> > reading the initial null value of st_200? No, because there is no
> > happens-before order involved here. So what kind of constructs introduce
> > happens-before order? This question is also addressed in the same section
> > of JLS:
> >
> > It follows from the above definitions that:
> >
> > -
> >
> > An unlock on a monitor *happens-before* every subsequent lock on that
> > monitor.
> > -
> >
> > A write to a volatile field (ยง8.3.1.4
> > <
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.3.1.4>
> > ) *happens-before* every subsequent read of that field.
> > -
> >
> > A call to start() on a thread *happens-before* any actions in the
> > started thread.
> > -
> >
> > All actions in a thread *happen-before* any other thread successfully
> > returns from a join() on that thread.
> > -
> >
> > The default initialization of any object *happens-before* any other
> > actions (other than default-writes) of a program.
>
> Thank you. That helps fill in a few gaps. Putting it into my own words
> to check my understanding:
>
> - The two reads in T2 may be re-ordered because, in T2, there is nothing
> that requires a happens-before relationship between the two reads
>
> - If T2 was executing in isolation the order of the reads wouldn't
> matter
>
> - However, T1 is writing.
>
> So if the writes in T2 are re-ordered and the write from T1 takes place
> between them the T2 read for the line 'st_200 == null' could return a
> non-null value for st_200 (the value after the write from T1) while the
> read for the line 'return st_200;' could return null (the value from
> before the write in T1).
>
> Is my understanding correct?
>
Not really. I have been trying to avoid getting into the discussion about
the low-level stuffs such as instruction reordering and caching. Let's stay
on the abstraction level of JMM. When reasoning on the level of JMM, one
should not care about reordering or speculative read. The happens-before
order is the only thing that matters. I know it could be confusing because
of the name, but happens-before order is orthogonal to whether two
operations can be reordered. The latter is the low-level detail that JMM
abstracts away. The first read in T2 does happen-before the second read
because of the intra-thread semantics (sorry, I forgot to include
intra-thread semantics when I pasted the constructs that introduce HB
order). However, in order to reason about what value the second read can
see, one has to stick to the two rules specified by JMM I quoted in my
previous message. In short, when reasoning with JMM, just assume the
instructions are executed in the same order as in the source code and start
reasoning about what value a read can see from there.
Yilong
>
> >> I don't have any particular issues in mind, just a suspicion that
> >> concurrency issues lie behind some of the hard to reproduce bugs that
> >> get reported from time to time. If I could produce the bug I would have
> >> fixed it already.
> >>
> >
> > Technically speaking, RV-Predict doesn't require a developer to be able
> to
> > produce the bug or data race in order to detect it. One can run
> RV-Predict
> > on code that fails only intermittently and RV-Predict may still catch the
> > bug. Perhaps it can be helpful to ask the bug reporter to run their code
> > against RV-Predict if it's just too hard to extract a test case that can
> > reproduce the failure consistently enough.
>
> Good to know. That is certainly worth a try. I'll add something to the
> bugs in question.
>
> > Thanks again for the prompt responses and the quick fixes of the reported
> > bugs. This has also helped RV-Predict to get into a better shape.
>
> Thanks to you to. It has certainly helped Tomcat improve and the
> discussion around these issues continues to help educate the community
> as a whole about these issues.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
