Statics and Thread Safety

[Greg Reddin <Gr...@alltel.com>]

I have some issues with thread safety and could use some advice.  Please look at
my assumptions and tell me if they are true or not.

1)  Tomcat (or other container) creates one instance of the ActionServlet,
ActionBase, and all my Action classes and caches them for performance reasons. 
Therefore multiple threads that come in are accessing the same instance.  Is
this true across all containers (i.e. is it part of the servlet spec)?

2)  Because multiple threads are accessing Actions, all the data used in an
Action must be on the stack.  In other words everything must be passed into
perform() or be local to perform().  I can't create class-level data in an
Action unless all access to it is synchronized.  And overuse of synchronized
data can slow down the app because threads have to wait for the code to be freed
up.

3)  Using static utility methods is thread safe because parameters passed into
static methods are on the stack and method-scoped data created in a static
method is on the stack.  So if I have the following code:

public static void doStuff(A a, B b)
{
        C c = new C();
        c.modifyC(a);
        b.doSomething(c);
}

I'm not in any thread danger here because each thread has it's own copy of a, b,
and c.  Is this correct?

Are there any other threading issues with static methods that I need to be aware
of?

Thanks,
Greg

Re: Statics and Thread Safety

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Greg Reddin wrote:

> I have some issues with thread safety and could use some advice.  Please look at
> my assumptions and tell me if they are true or not.
>
> 1)  Tomcat (or other container) creates one instance of the ActionServlet,
> ActionBase, and all my Action classes and caches them for performance reasons.
> Therefore multiple threads that come in are accessing the same instance.  Is
> this true across all containers (i.e. is it part of the servlet spec)?
>

Yes.

More precisely, there is one instance of these things per web application, but
that
doesn't really matter for the concerns you are raising here.

>
> 2)  Because multiple threads are accessing Actions, all the data used in an
> Action must be on the stack.  In other words everything must be passed into
> perform() or be local to perform().  I can't create class-level data in an
> Action unless all access to it is synchronized.  And overuse of synchronized
> data can slow down the app because threads have to wait for the code to be freed
> up.
>

Yes, but whether synchronization is required or not is a bit more complex than
that.  Consider several cases:

* I'm using a Hashtable as an instance variable in an Action.
  I don't need to synchronize around get() and put() calls,
  because the underlying class guarantees to do so for me.
  (NOTE:  the objects I store inside the Hashtable may well
  have synchronization issues ... it's sort of a recursive problem :-).

* I'm using a HashMap as an instance variable in an Action.
  If there are reads and writes going on from multiple threads,
  then I definitely need to synchronize around all accesses to
  the HashMap.  However, if the only writes happen at startup
  time (say, in the constructor), and everything else is just reads,
  you don't -- read operations are non-desctructive so they can
  run simultaneously.

>
> 3)  Using static utility methods is thread safe because parameters passed into
> static methods are on the stack and method-scoped data created in a static
> method is on the stack.  So if I have the following code:
>
> public static void doStuff(A a, B b)
> {
>         C c = new C();
>         c.modifyC(a);
>         b.doSomething(c);
> }
>
> I'm not in any thread danger here because each thread has it's own copy of a, b,
> and c.  Is this correct?
>

That's correct.  The fact that this method is static or not actually doesn't
matter
-- the same is true for an Action that does everything with local variables
(which
are on the stack).

>
> Are there any other threading issues with static methods that I need to be aware
> of?
>
> Thanks,
> Greg

Craig McClanahan