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?
>> 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
