• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

SingleThreadModel question

 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In the sample Web Component Developer test that Sun sells for $50, the answer to a similar question to the one below is given as [A]. (I�ve modified the question superficially to hopefully avoid any copyright infringements).
Shouldn�t the answer be D? The Servlet 2.2 API documentation for the SingleThreadModel interface states, "this interface does not prevent synchronization problems that result from servlets accessing shared resources such as static class variables or classes outside the scope of the servlet".
-------------
Question:
Given:
1. public class TestServlet extends HttpServlet implements SingleThreadModel {
2. private static int num = 5;
3. public void doGet(HttpServletRequest req, HttpServletResponse resp) {
4. // do nothing;
5. }
6. }
Which statement is true?
A) Variables num and req are both thread safe
B) Variables num and req are both not thread safe
C) Variable num is thread safe, while variable req is not thread safe
D) Variable num is not thread safe, while variable req is thread safe
 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The question is a bit tricky, no doubt answer appears to be D. Here is an attempt to justify the sun's answer. As the variable num is static it is not associated to a particular instance but being a private member it cannot be accessed using Class.method() syntax. The only way of changing the value of this variable is to set it within the class. So here is a variable that can only be changed by
1)class's methods
2)static initializer
3)instance initializer
But in the case of this question none of above is changing value of the variable num. That's what make it thread safe. I drew this conclusion from the comment in the doGet... //do nothing
Just a guess
 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Shamaila - I got two questions for clarification purposes. So if num was not a private variable then num would not be thread safe. Or if within doGet, num is set to a different value then num would not be threadsafe also.
Just making sure I understood your explanation. This is a very tricky question.
 
Shamaila Mahmood
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Khanh Nguyen:
Shamaila - I got two questions for clarification purposes. So if num was not a private variable then num would not be thread safe. Or if within doGet, num is set to a different value then num would not be threadsafe also. (


(first question) If num was not a private variable:
Actually static variable are not thread safe as all the instances of this class can access/modify them either by onjectName.staticVariableName or by ServletClassName.staticVariableName,
but as num is a private variable so you can not access it in either of these two ways.
But any method of the servlet class can modify its value. so all the instances of servlet class can modify the same static variable even if it is private. That's why private static variables can not be considered as thread safe.
(second question)if within doGet, num is set to a different value then num would not be threadsafe also:
In all the cases where we know that no method of the servlet class modify the value of a variable(static or instance) then we can say that this variable is theard safe. So thread safety of a variable depends upon the code. means depending on the imlementation of the servlet you can say that a particualr variable is thread safe even if the variable is an instance variable.
 
Ranch Hand
Posts: 150
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Shamaila Mahmood:
Here is an attempt to justify the sun's answer.


All praise for a very creative answer, but if that really is Sun's intention (and not just a mistake), then I'd say it is a trick question.
 
Sheriff
Posts: 3341
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think Sun is wording the question improperly. In this example, (IMHO) num is not ThreadSafe. Implementing the SingleThreadedModel doesn't change this. However, since SingleThreadedModel ensure that only one thread can be in the service method at a time, Operations can safely occur on num in the service method without be impacted by another thread (Which is what Thread Safety is all about).
So, as I see it Sun is actually asking "Which of these variable can be safely manipulated in the service method of a servlet that implements the SingleThreadedModel?
 
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Carl - Suppose the container is enforcing the thread safety through instance pooling (and not serialization of requests). So now we can have multiple instances of the servlet running, and we know that only one thread is running through the service method of each instance. Now we have multiple threads (each running through a separate instance) with access to the same shared resource num. It seems like in this case we could have problems with num. What am I missing here?
 
Tim Duncan
Ranch Hand
Posts: 150
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Isn't the position complicated by the possibility of pooling?
I thought (and I'm not particularly confident here) that the SingleThreadedModel ensures that a servlet instance can only be accessed by a single thread at one time. However some servers provide a pool of servlet instances to handle requests.
If "num" was a simple instance variable then it would be thread-safe under the SingleThreadedModel, but since it is static it can be accessed by other instances of the servlet, and hence by other threads.
Have I got this right?

 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm now certain that Sun either worded this question improperly or they have a typo in their answer. They had a similar question in the SCWCD exam I took yesterday, and there, I regarded the static private variable as non-thread-safe (eventhough it was not being referenced by any method or initializer code), and the answer was marked correct.
BJ and Tim are both correct. The static variable num is not thread safe. This is true with or without SingleThreadModel.
(a) When not implementing SingleThreadModel, there is the risk that multiple service requests or multiple named instances of the servlet (registered via <servlet-name> ) can modify the static variable simultaneously.
(b) When implementing SingleThreadModel, there is still the risk that num is modified by multiple pool instances or multiple named instances simultaneously.
But regardless, it's just not a good idea to use static variables to share state. Not only is it not thread-safe, but if you ever want to make your web application distributable in the future, you'll have to eliminate such code, since a servlet in this configuration will have different instances loaded on different JVM's and hence by different class loaders. So, they will not be able to see each other's class variables.

[This message has been edited by Miftah Khan (edited September 20, 2001).]
 
BJ Grau
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Great!! Congrats on passing the exam, and thanks for confirming my thoughts. I was in dire need of somebody to come in here and set me straight. SingleThreadModel has been a problem for me due to hearing conflicting ideas from folks at work and reading conflicting information about it. Now I've got it. Thanks.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic