On 27 September 2010 21:34, Ohad Shacham wrote:
> ConcurrentHashMap does not support null keys and entries.
Did not check that. However, the attributes Map field is protected and
not final, so it could in theory be replaced with a Map that allows
dupes.
That's perhaps another bug...
--
> From: ohad.shac...@gmail.com [mailto:ohad.shac...@gmail.com] On Behalf Of
> Ohad Shacham
> Subject: Re: Atomicity violation in removeAttribute
> I would use:
> if (attributes.containsKey(name)) {
> value = attributes.remove(name);
> if (value == null)
>
> If get() cannot return null, then I think one can just use:
> value = attributes.remove(name);
> if (value == null)
> return;
> If it is important to distinguish null entries from missing entries,
> then a different approach is needed - e.g. AtomicReference as
> suggested elsewhere
Concu
On 26 September 2010 15:00, Ohad Shacham wrote:
> Hi,
>
>
> In addition to the behavior we experienced in function setAttribute. We also
> experienced another atomicity violation in function removeAttribute.
>
> The following code is located at the beginning of function removeAttribute
> at class
Hello,
I'd rather use the compareAndSet method in AtomicReference for this
particular task.
On Sun, Sep 26, 2010 at 4:00 PM, Ohad Shacham wrote:
> Hi,
>
>
> In addition to the behavior we experienced in function setAttribute. We
> also
> experienced another atomicity violation in function rem
Hi,
In addition to the behavior we experienced in function setAttribute. We also
experienced another atomicity violation in function removeAttribute.
The following code is located at the beginning of function removeAttribute
at class ApplicationContext. This code fragment intends to check whethe
