On Tue, Sep 15, 2015 at 1:09 PM, Mark Thomas wrote:
> On 15/09/2015 20:42, Caldarale, Charles R wrote:
> >> From: Mark Thomas [mailto:ma...@apache.org]
> >> Subject: Re: RV-Predict bugs
> >
> >> Putting it into my own words to check my understanding:
> >
> >> - The two reads in T2 may be re-order
> From: Yilong Li [mailto:yilong...@runtimeverification.com]
> Subject: Re: RV-Predict bugs
> Nope, I know what I am doing. Let's first see what the expert says. Please
> check out the last section in this article (
> http://jeremymanson.blogspot.com/2008/12/benign-data-races-in-java.html)
> whic
On 15/09/2015 20:38, Mark Thomas wrote:
> On 15/09/2015 20:15, Mark Thomas wrote:
>> On 15/09/2015 18:28, Felix Schumacher wrote:
>>> Hi Mark,
>>>
>>> Am 15.09.2015 um 14:45 schrieb ma...@apache.org:
Author: markt
Date: Tue Sep 15 12:45:48 2015
New Revision: 1703177
URL: ht
Author: markt
Date: Tue Sep 15 21:10:30 2015
New Revision: 1703290
URL: http://svn.apache.org/r1703290
Log:
Follow-up to r1703177.
Ensure that members never contains an intermediate result of the sorting
process.
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.ja
Author: markt
Date: Tue Sep 15 21:11:52 2015
New Revision: 1703291
URL: http://svn.apache.org/r1703291
Log:
Follow-up to r1703177.
Ensure that members never contains an intermediate result of the sorting
process.
Modified:
tomcat/tc8.0.x/trunk/ (props changed)
tomcat/tc8.0.x/trunk/jav
https://bz.apache.org/bugzilla/show_bug.cgi?id=58384
Mark Thomas changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #2 from Mark Thomas
Author: markt
Date: Tue Sep 15 21:19:00 2015
New Revision: 1703294
URL: http://svn.apache.org/r1703294
Log:
Revert r1703194. Bug report was a false positive.
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
Modified:
tomcat/trunk/java/org/apache/tomcat/webso
https://bz.apache.org/bugzilla/show_bug.cgi?id=58384
--- Comment #3 from Yilong Li ---
Interesting, I have my reservations on this. I will find some time to
investigate it further. Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
---
https://bz.apache.org/bugzilla/show_bug.cgi?id=58411
--- Comment #4 from Steve Davids ---
I have a distributed system that needs to collect data on each data node and
stream it back to the client in a timely manner, so I go ahead and open up
multiple concurrent InputStreams from each data node an
The Buildbot has detected a build exception on builder tomcat-trunk while
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-trunk/builds/287
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: silvanus_ubuntu
Build Reason: The AnyBranchSch
On 15/09/2015 21:51, Yilong Li wrote:
> On Tue, Sep 15, 2015 at 1:09 PM, Mark Thomas wrote:
>
>> On 15/09/2015 20:42, Caldarale, Charles R wrote:
From: Mark Thomas [mailto:ma...@apache.org]
Subject: Re: RV-Predict bugs
>>>
Putting it into my own words to check my understanding:
>>>
Sorry, I am confused. So you are saying that the author of JMM
misunderstands his own work? Well, I highly doubt that. I don't understand
why you interpret JMM in a way that excludes intra-thread semantics. How is
it possible for JMM to be of any use if it does not take into account the
intra-threa
> From: Mark Thomas [mailto:ma...@apache.org]
> Subject: Re: RV-Predict bugs
> st_200 is non-volatile
> L1 if (st_200 == null ) {
> L2st_200 = sm.getString("sc.200");
> L3 }
> L4 return st_200;
> Ln=Line n
> Tx=Thread x
> Rn=Read at line n
> Wn=Write at line n
> So T2 has two reads, T2R1 a
The Buildbot has detected a restored build on builder tomcat-8-trunk while
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-8-trunk/builds/126
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: silvanus_ubuntu
Build Reason: The AnyBranch
https://bz.apache.org/bugzilla/show_bug.cgi?id=58411
Mark Thomas changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://bz.apache.org/bugzilla/show_bug.cgi?id=58414
Bug ID: 58414
Summary: It is not possible to transfer empty string through
Web Socket
Product: Tomcat 8
Version: 8.0.26
Hardware: PC
Status: NEW
Sev
https://bz.apache.org/bugzilla/show_bug.cgi?id=58411
--- Comment #6 from Remy Maucherat ---
Really ? Those (legacy) Servlet objects have never been synced.
--
You are receiving this mail because:
You are the assignee for the bug.
On Tue, Sep 15, 2015 at 2:33 PM, Mark Thomas wrote:
> On 15/09/2015 21:51, Yilong Li wrote:
> > On Tue, Sep 15, 2015 at 1:09 PM, Mark Thomas wrote:
> >
> >> On 15/09/2015 20:42, Caldarale, Charles R wrote:
> From: Mark Thomas [mailto:ma...@apache.org]
> Subject: Re: RV-Predict bugs
> >
https://bz.apache.org/bugzilla/show_bug.cgi?id=58404
Christopher Schultz changed:
What|Removed |Added
Status|NEEDINFO|NEW
--- Comment #3 from Christop
https://bz.apache.org/bugzilla/show_bug.cgi?id=58414
Evgeny Mironenko changed:
What|Removed |Added
Summary|It is not possible to |Can not transfer empty
On 15/09/2015 22:34, Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Subject: Re: RV-Predict bugs
>
>> st_200 is non-volatile
>
>> L1 if (st_200 == null ) {
>> L2st_200 = sm.getString("sc.200");
>> L3 }
>> L4 return st_200;
>
>> Ln=Line n
>> Tx=Thread x
>> Rn=R
On 15/09/2015 22:55, Yilong Li wrote:
> Fine. Let's do your example:
> T2R4 (out of order read returns null)
> T1R1 (returns null)
> T1W2 (writes non-null value)
> T1R4 (reads new non-null value)
> T2R1 (reads new non-null value)
>
> First of all, when reasoning with JMM, you should not move T2R4
> From: Mark Thomas [mailto:ma...@apache.org]
> Subject: Re: RV-Predict bugs
> To make sure I understand this it is the possibility of the write T2W2
> that is sufficient to ensure T2R1 and T2R4 are not re-ordered not the
> possibility of a write in some other thread?
Section 14.2 requires that
https://bz.apache.org/bugzilla/show_bug.cgi?id=58411
--- Comment #7 from Mark Thomas ---
I was all for closing it as INVALID as well then I went I dug through the
Javadoc. Is there anything you can recall in the Servlet spec, javadoc or the
EG discussions that points to the PrintWriter being thre
On 15/09/2015 23:09, Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Subject: Re: RV-Predict bugs
>
>> To make sure I understand this it is the possibility of the write T2W2
>> that is sufficient to ensure T2R1 and T2R4 are not re-ordered not the
>> possibility of a
On Tue, Sep 15, 2015 at 3:09 PM, Mark Thomas wrote:
> On 15/09/2015 22:55, Yilong Li wrote:
>
> > Fine. Let's do your example:
> > T2R4 (out of order read returns null)
> > T1R1 (returns null)
> > T1W2 (writes non-null value)
> > T1R4 (reads new non-null value)
> > T2R1 (reads new non-null value)
The Buildbot has detected a new failure on builder tomcat-8-trunk while
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-8-trunk/builds/127
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: silvanus_ubuntu
Build Reason: The AnyBranchSch
I have been having a hard time believing the reordering claims, but finally I
went to Jeremy’s blog post. To recap, he says
if (hash == 0) {
int h = //compute hash
hash = h;
}
return hash;
can be reordered to
r1 = hash;
if (hash == 0) {
r1 = hash = // calculate hash
}
return r1;
Obviou
> From: Yilong Li [mailto:yilong...@runtimeverification.com]
> Subject: Re: RV-Predict bugs
> So you are saying that the author of JMM misunderstands his own work?
No, I'm saying that he's only looking at things from the point of view of 17.4,
and ignoring section 14.2 of the JLS. (BTW, prior
> From: David Jencks [mailto:david_jen...@yahoo.com.INVALID]
> Subject: Re: RV-Predict bugs
> I have been having a hard time believing the reordering claims, but finally I
> went to Jeremy's
> blog post. To recap, he says
> if (hash == 0) {
> int h = //compute hash
> hash = h;
> }
> retu
> From: Mark Thomas [mailto:ma...@apache.org]
> Subject: Re: RV-Predict bugs
> I understand that the JMM allows this behaviour. I don't understand how
> this could happen in a JVM implementation.
I don't believe it can, on any supported hardware.
> If T2R1 has read a non-null value how could a
> From: Mark Thomas [mailto:ma...@apache.org]
> Subject: Re: RV-Predict bugs
> My expectation is that once T2 has seen the updated value (originated
> from another thread) all subsequent reads in T2 of the same field are
> going to see the same value rather than some of those reads seeing an
> ol
Your argument seems to assume that reordering is the only code
transformation that can be done by compiler or hardware. I don't agree that
you call this transformation a red herring. It might not be practical but
it's certainly valid. Does it violate the intra-thread semantics you
mentioned in JLS
On Tue, Sep 15, 2015 at 6:29 PM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:
> > From: Yilong Li [mailto:yilong...@runtimeverification.com]
> > Subject: Re: RV-Predict bugs
>
> > So you are saying that the author of JMM misunderstands his own work?
>
> No, I'm saying that he's only l
Am 15. September 2015 23:10:30 MESZ, schrieb ma...@apache.org:
>Author: markt
>Date: Tue Sep 15 21:10:30 2015
>New Revision: 1703290
>
>URL: http://svn.apache.org/r1703290
>Log:
>Follow-up to r1703177.
>Ensure that members never contains an intermediate result of the
>sorting process.
>
>Modified
https://bz.apache.org/bugzilla/show_bug.cgi?id=58411
--- Comment #8 from Steve Davids ---
PrintWriter doesn't say anything specifically about thread safety but the
Writer implies it with the constructor saying:
http://docs.oracle.com/javase/8/docs/api/java/io/Writer.html#Writer--
> Creates a new
https://bz.apache.org/bugzilla/show_bug.cgi?id=58416
Bug ID: 58416
Summary: Possibly wrong check condition in catalina.sh
Product: Tomcat 7
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: minor
https://bz.apache.org/bugzilla/show_bug.cgi?id=58416
ko_nakam...@sdcns.co.jp changed:
What|Removed |Added
CC||ko_nakam...@sdcns.co.jp
--
Y
At this point I tend to agree with Ylong and Jeremy. I’m very far from being
an expert but I thought 14.2 meant that the result of execution of a single
thread had to be the same as if it executed the given instructions in the order
supplied. I didn’t think it meant it had to execute those par
101 - 139 of 139 matches
Mail list logo
