>if count was not used as
>a part of the CounterCons class then count would need to be synchronized?
It depends. If count were to be shared at least among threads going through
a servlet instance, it would have to be synchronized if it were used in a
non atomic way.
That is, if count is local to the doGet method, or if it belong to an object
which is referenced only locally in this method, no one else have access to
it, so it don't need to be synchronized. (But beware, many bugs arrise when
you *think* something is not referenced eslewhere.)
If count is shared among threads, that is , for example, if it is a member
of the servlet instance, it might be non synchronized, depending on what you
want to do with it.
If you only read from it, there are generally no need to synchronise. The
only problem is that it might not be up to date when you access it. For
example, in the following code :
... class My Servlet ... {
int count;
... doGet ... {
... do something
out.println(count);
... do something else
out.println(count);
}
}
You might end with two different values of count because another thread
would have come and modify it between the to println. (Of course, there must
be code somewhere else in the the servlet to modify count, let's say in
another method.)
If you write and read to and from count, you need to synchronise because you
"much more probably" ;-) do this kind of non atomic use of it :
... class My Servlet ... {
int count;
... doGet ... {
... do something
count++;
out.println(count);
}
}
Here, count might be modified by another thread between incrementation and
display. Typically, you will sometimes end with a value that is one more
than expected.
You can't avoid synchronizing doing :
out.println(++count);
because this is not atomic neither. Atomicity is to be considered at a much
deeper level. (It depends on who is scheduling the threads : Java or the
underlying system).
A more interesting problem is if you only write to count. What about the
following :
count = count + 1;
This involves :
reading count
adding one
storing the result in count
A second thread could possibly read count after the first read but before
the first write. In that case, you would end with a value that is one less
than expected.
Does "count++" solve this problem ?
To answer these question, you have to check the Java specifications. If you
have no time for this, you would probably better synchronize anyway.
Pierre-Yves
-----Message d'origine-----
De : A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]De la part de
James Wilson
Envoyé : dimanche 22 avril 2001 08:42
À : [EMAIL PROTECTED]
Objet : Re: [Re: Servlets constructors]
Ok, I see the distinction. Just to make it clear, if count was not used as
a part of the CounterCons class then count would need to be synchronized?
Is this correct? I really would like to see CounterCons as a class out-side
of HttpServlet, like you said.
-----Original Message-----
From: A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of
Saumont Pierre-Yves
Sent: Saturday, April 21, 2001 2:19 PM
To: [EMAIL PROTECTED]
Subject: Re: [Re: Servlets constructors]
Because the reference to the counter (an instance of the servlet) is local
to the doGet method. So, it will not be shared among the threads making
their ways through the method. What may confuse you is that count is an
instance member. As such, it is shared by all thread going through the
object being referenced by countercons. This is a reference to an object of
the same class as our servlet, but is is *not* our servlet. It's an entirely
separate object. As count is not static, it is not shared among instances of
CounterCons. Each thread going through our servlet will create its own
countercons with it's own counter. (And the servlet will just old a
reference to an object of the same class as itself. This is a very common
situation. But in the present case, it's very poor desing. If you need a
counter object, it is much preferable to create a separate class !)
Pierre-Yves
-----Message d'origine-----
De : A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]De la part de
James Wilson
Envoyé : samedi 21 avril 2001 20:17
À : [EMAIL PROTECTED]
Objet : Re: [Re: Servlets constructors]
Why doesn't that piece need to be synchronized?
-----Original Message-----
From: A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of
Saumont Pierre-Yves
Sent: Saturday, April 21, 2001 4:57 AM
To: [EMAIL PROTECTED]
Subject: Re: [Re: Servlets constructors]
Just for the fun, here is the original code revisited :
import java.io.*;
import javax.servlet.http.*;
import javax.servlet.*;
public class CounterCons extends HttpServlet {
int count;
public CounterCons (){}
public CounterCons (int i)
{
count=i;
}
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws IOException {
CounterCons countercons = new CounterCons (1122);
PrintWriter out=res.getWriter();
countercons .count++;
out.println(countercons .count);
}
}
(Mark, note that there is no need to synchronize !)
But wait, this is cheating. The original poster didn't want any reference
created. So here is the solution :
import java.io.*;
import javax.servlet.http.*;
import javax.servlet.*;
public class CounterCons extends HttpServlet {
int count;
public CounterCons (){}
public CounterCons (int i) {
count=i;
}
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws IOException {
res.getWriter().println(++((new CounterCons(1122)).count));
}
}
Pierre-Yves
P.S. Just kidding (for those who didn't notice)
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
