On 01/06/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-06-01 at 15:29 +0100, sebb wrote:
>  > It looks like BasicHttpParams is not thread-safe.
>  >
>  > Although it uses a HashMap (which is thread-safe) to store parameters,
>  > the instance variable which holds it is not final or volatile, and
>  > accesses to it are not synchronized.
>  >
>  > If one thread calls setParameter() and creates the HashMap, there is
>  > no guarantee that another thread will see the HashMap.
>  >
>  > One solution would be to always create the HashMap (in the ctor or in
>  > the variable defn).
>  > This would mean some internal changes - e.g. clear() - but are there
>  > any drawbacks to always creating the HashMap?
>  >
>  > S///
>  >
>
>
> Sebastian,
>
>  It is performance trade-off. HttpParams are meant to be treated as
>  immutable once initialized. It is 'write once - read many' kind of
>  structure. So, we left BasicHttpParams uninitialized for performance
>  reasons, as they tend to be read from quite a lot.

In which case, maybe it would be better to ensure that the map always
exists, and avoid the null checks?  This would sometimes use extra
memory however.

>  This just needs to be
>  documented properly (like so many other things. Oh well...)
>

I was thinking of adding the @Immutable, @ThreadSafe etc annotations
to the Java 1.4 classes as well, but as comments.

If the core classes ever move to 1.5+, then the comments could be
turned into proper annotations.

>  Oleg
>
>
>
>
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to