atomicity violation in the JspServletWrapper class ?
Dear all:
Can you help me analyze the following simplified synchronization
code in tomcat (the servlet function of JspServletWrapper class), I
think it involves an atomicity violation, the detailed explanation is as
follows:
service(Request request, Response response...)
{
if (development_mode) {// the jsp file
// may be updated on the fly
synchronized (this) {...
ctxt.compile(); ...
}
}
synchronized(this) { getServlet();}
if (mt_mode) { // sync to guarantee the
//freshness right before servicing
synchronized (this) {
theServlet.service(request, response);
}
}
}
The service function of JspServletWrapper class processes the incoming
request from a JSP file. In particular, it creates a class
(servletClass) to represent the JSP file, and instantiates an instance
(theServlet) of the class, and then uses the instance to serve the
request.
The class (servletClass) is created at runtime for a JSP file, and
should be updated on the fly once the JSP file changes at runtime. In
the code The (compile) invocation checks the freshness of
servletClass, updates and stores it if necessary. The (getServlet)
invocation retrieves the stored servletClass class and uses it to
create an instance theServlet. The (service) invocation uses the
(theServlet) instance to serve the request. The expected semantic is
that the (service) invocation should use the instance of the most
up-to-date (servletClass). However, the semantic is not preserved by
the original atomic regions due to atomicity violations: the retrieved
(servletClass) by the (getServlet) invocation may be stale as the
(servletClass) may be updated by the other thread since last (compile)
invocation. Even if there is no buggy interleaving between the first
two invocations, there may be an interleaving write to (theServlet)
between the second and third invocation, which makes (theServlet) used
by the third invocation stale. Note that, however, the implementation
of (getServlet) method protects servletClass and theServlet in an atomic
region to avoid the interleaving update of (servletClass} before
instantiating (theServlet).
Thank you sincerely for your help.
Regards
Peng
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: atomicity violation in the JspServletWrapper class ?
Dear Thomas: Thank you very much. Regards Peng Mark Thomas wrote: On 05/03/2011 19:30, lpxz wrote: It would of helped if you had mentioned which Tomcat version you were looking at. I'm assuming trunk. The expected semantic is that the (service) invocation should use the instance of the most up-to-date (servletClass). Where is that stated? My expectation is that at least the most recent servletClass at the point the service() method is called is used. If the source JSP is changed while the service() method is executing and the newer version is used, great. If not, it is not an issue. However, the semantic is not preserved by the original atomic regions due to atomicity violations: the retrieved (servletClass) by the (getServlet) invocation may be stale as the (servletClass) may be updated by the other thread since last (compile) invocation. This is handled by the reload attribute. If thread 1 calls getServlet() before thread 2 sets reload=true that is fine. Even if there is no buggy interleaving between the first two invocations, there may be an interleaving write to (theServlet) between the second and third invocation, which makes (theServlet) used by the third invocation stale. If I have understood you correctly, then I think you have a point here. It would be better to store the return value of getServlet() and use that throughout the rest of the service() method rather than using theServlet. I'll get that fixed shortly. It will be in 7.0.11 onwards and I'll propose it for back-port to 6.0.x and 5.5.x as well (assuming they have the same issue). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: atomicity violation in the JspServletWrapper class ?
Dear Thomas: I am using the tomcat 6 in the dacapo-9.12-bach, sorry that I can not figure out the detailed version number. Regards Peng lpxz wrote: Dear Thomas: Thank you very much. Regards Peng Mark Thomas wrote: On 05/03/2011 19:30, lpxz wrote: It would of helped if you had mentioned which Tomcat version you were looking at. I'm assuming trunk. The expected semantic is that the (service) invocation should use the instance of the most up-to-date (servletClass). Where is that stated? My expectation is that at least the most recent servletClass at the point the service() method is called is used. If the source JSP is changed while the service() method is executing and the newer version is used, great. If not, it is not an issue. However, the semantic is not preserved by the original atomic regions due to atomicity violations: the retrieved (servletClass) by the (getServlet) invocation may be stale as the (servletClass) may be updated by the other thread since last (compile) invocation. This is handled by the reload attribute. If thread 1 calls getServlet() before thread 2 sets reload=true that is fine. Even if there is no buggy interleaving between the first two invocations, there may be an interleaving write to (theServlet) between the second and third invocation, which makes (theServlet) used by the third invocation stale. If I have understood you correctly, then I think you have a point here. It would be better to store the return value of getServlet() and use that throughout the rest of the service() method rather than using theServlet. I'll get that fixed shortly. It will be in 7.0.11 onwards and I'll propose it for back-port to 6.0.x and 5.5.x as well (assuming they have the same issue). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
