tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ohad Shacham <ohad.shac...@cs.tau.ac.il>
Subject Re: Atomicity violation in setAttribute
Date Mon, 27 Sep 2010 15:08:36 GMT
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 <timw@apache.org> wrote:

> 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 temporary internal inconsistency isn't going to
> hurt.
>
> > val = attributes.put(name, value);
> > if (val != null)
> >    replaced = true;
>
> +1 - this is simpler in any case.
>
> cheers
> tim
>
> On Mon, Sep 27, 2010 at 6:25 AM, Ian Darwin <ian@darwinsys.com> wrote:
> >>  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.
> >>
> >> Could you please let me know whether you consider this as a bug?
> >
> > Is it any different than if two threads invoke the operation serially?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message