velocity-user mailing list archives

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

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. [mailto:geirm@optonline.net]
Sent: Monday, October 01, 2001 3:48 PM
To: velocity-user@jakarta.apache.org
Subject: Re: Thread safety


On 10/1/01 5:29 PM, "Brian Goetz" <brian@quiotix.com> 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
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.

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

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


geir

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



Mime
View raw message