velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Glass-Husain" <>
Subject RE: Thread safety
Date Tue, 02 Oct 2001 00:48:28 GMT

Just downloaded Velocity 1.2rc1.  Look forward to installing.

This is a basic question-- but what's the difference between a rc version
and a regular version?  (Maybe there's a FAQ I should be checking on open
source development?)

Thanks, WILL

-----Original Message-----
From: Geir Magnusson Jr. []
Sent: Monday, October 01, 2001 3:48 PM
Subject: Re: Thread safety

On 10/1/01 5:29 PM, "Brian Goetz" <> wrote:

>> 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
>> #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.

Exactly.  And that's 'VelocityContext'.

>> 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
>> 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
> make it not thread-safe.)

#2 and #3 are probably not required, but I just got home and haven't given
it deep thought.


Geir Magnusson Jr.
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin

View raw message