Given that there is a violation, and the proposed solution is simpler, would
you take it in the next release?
Thanks,
Ohad
On Sun, Sep 26, 2010 at 10:42 PM, Tim Whittington wrote:
> This is technically a race condition, but given the vague information
> provided in ServletContextAttributeEvent
This is technically a race condition, but given the vague information
provided in ServletContextAttributeEvent (e.g. the inability to
differentiate adds vs replaces) I can't see it causing a real problem.
i.e. there's no atomicity in the interaction of an attribute listener
with the context, so a t
> In this case, both threads will
> continue running the function with ?replaced? bit turned on and the oldValue
> of both thread will point to the same location. This means that the value of
> the first thread that did the put operation will not be treated as a value
> that was replaced.
>
> Cou
Hi,
We are building a tool for detecting non atomic usages of concurrent
collections.
We analyzed Tomcat’s code using our tool and found the following behavior:
The following code is located at the beginning of function setAttribute at
class ApplicationContext. This code fragment intends t
