You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bi...@apache.org on 2003/12/25 04:08:31 UTC
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java
billbarker 2003/12/24 19:08:31
Modified: util/java/org/apache/tomcat/util/threads ThreadPool.java
Log:
Fix potential race condition.
You'll need some pretty high-end hardware to see this in the real world, but it's still technically a bug.
Revision Changes Path
1.19 +1 -1 jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
Index: ThreadPool.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- ThreadPool.java 6 Nov 2003 19:05:23 -0000 1.18
+++ ThreadPool.java 25 Dec 2003 03:08:31 -0000 1.19
@@ -638,9 +638,9 @@
t = new ThreadWithAttributes(p, this);
t.setDaemon(true);
t.setName(p.getName() + "-Processor" + p.getSequence());
- t.start();
p.addThread( t, this );
noThData=true;
+ t.start();
}
public void run() {
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads
ThreadPool.java
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> I was thinking that on a big enough SMP machine it would be possible to
> check noThreadData before the constructor exists. Of course, it's not since
> the check is after the wait(), and notify() can't be called until the
> constructor exits. I realized this about half an hour after the commit, but
> it didn't seem worth reverting. I can revert it if people want.
This is a little bit more correct, so I recommend to leave the patch in.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, December 25, 2003 1:15 AM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads
ThreadPool.java
> billbarker@apache.org wrote:
> > billbarker 2003/12/24 19:08:31
> >
> > Modified: util/java/org/apache/tomcat/util/threads ThreadPool.java
> > Log:
> > Fix potential race condition.
> >
> > You'll need some pretty high-end hardware to see this in the real
world, but it's still technically a bug.
>
> When can it occur, and what does the problem do ? All calls to
> openThreads are synced on the pool, so new threads should be created
> sequentially.
>
I was thinking that on a big enough SMP machine it would be possible to
check noThreadData before the constructor exists. Of course, it's not since
the check is after the wait(), and notify() can't be called until the
constructor exits. I realized this about half an hour after the commit, but
it didn't seem worth reverting. I can revert it if people want.
> > Revision Changes Path
> > 1.19 +1 -1
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPoo
l.java
> >
> > Index: ThreadPool.java
> > ===================================================================
> > RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads
/ThreadPool.java,v
> > retrieving revision 1.18
> > retrieving revision 1.19
> > diff -u -r1.18 -r1.19
> > --- ThreadPool.java 6 Nov 2003 19:05:23 -0000 1.18
> > +++ ThreadPool.java 25 Dec 2003 03:08:31 -0000 1.19
> > @@ -638,9 +638,9 @@
> > t = new ThreadWithAttributes(p, this);
> > t.setDaemon(true);
> > t.setName(p.getName() + "-Processor" + p.getSequence());
> > - t.start();
> > p.addThread( t, this );
> > noThData=true;
> > + t.start();
> > }
> >
> > public void run() {
>
> Rémy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads
ThreadPool.java
Posted by Remy Maucherat <re...@apache.org>.
billbarker@apache.org wrote:
> billbarker 2003/12/24 19:08:31
>
> Modified: util/java/org/apache/tomcat/util/threads ThreadPool.java
> Log:
> Fix potential race condition.
>
> You'll need some pretty high-end hardware to see this in the real world, but it's still technically a bug.
When can it occur, and what does the problem do ? All calls to
openThreads are synced on the pool, so new threads should be created
sequentially.
> Revision Changes Path
> 1.19 +1 -1 jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
>
> Index: ThreadPool.java
> ===================================================================
> RCS file: /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
> retrieving revision 1.18
> retrieving revision 1.19
> diff -u -r1.18 -r1.19
> --- ThreadPool.java 6 Nov 2003 19:05:23 -0000 1.18
> +++ ThreadPool.java 25 Dec 2003 03:08:31 -0000 1.19
> @@ -638,9 +638,9 @@
> t = new ThreadWithAttributes(p, this);
> t.setDaemon(true);
> t.setName(p.getName() + "-Processor" + p.getSequence());
> - t.start();
> p.addThread( t, this );
> noThData=true;
> + t.start();
> }
>
> public void run() {
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org