velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Goetz <br...@quiotix.com>
Subject RE: Thread safety
Date Mon, 01 Oct 2001 21:29:24 GMT

>Is there something fancy that goes on with the Context during the merge()
>that would make it non-thread-safe? Or is it just concern over the fact that
>#set() operations will change the content of the Context? (which isn't
>thread safe)

The Context is stateful, and its state is presumably stored in an 
unsynchronized map.  The cost of making it thread-safe doesn't seem to be 
worth it for the 0.01% of users who will be sharing the context across 
threads.  For them, its easy enough to synchronize all operations that 
would affect the Context.

>I haven't stress tested the hell out of it but I have a "default" context
>(with a bunch of global variables, tools, etc...) that I nest inside of the
>context that is created during each request ...
>
>VelocityContext ctx = new VelocityContext(defaultContext);
>
>is that safe?

A more complicated question.  Without looking at the code (look ma, no 
hands), I'd say this operation is technically only safe if the following 
conditions are met:
  - the default context is constructed before other threads that use it are 
created,
  - nothing is ever added to or removed from the default context after it 
is initially created and populated,
  - the objects that the default context references are similarly immutable.

(In reality, the first condition is probably not met, but there is almost 
certainly other synchronization that makes it work anyway, even though 
technically there could be race conditions on some architectures that would 
make it not thread-safe.)



--
Brian Goetz
Quiotix Corporation
brian@quiotix.com           Tel: 650-843-1300            Fax: 650-324-8032

http://www.quiotix.com


Mime
View raw message