Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Robert Klemme <shortcutter@googlemail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: unchecked conversion warning.
Date: Tue, 19 Jun 2012 23:14:06 +0200
Lines: 65
Message-ID: <a4c8d9Fsh9U1@mid.individual.net>
References: <3s7cs7hd18l0ffci55ns0286n4lc4cutlu@4ax.com> <265ea956-a3ed-4e76-8fc9-9ce9728f6b37@googlegroups.com> <vOmdnf2Cqs6MBEjSnZ2dnUVZ_tSdnZ2d@earthlink.com> <a43fb8Fj1vU1@mid.individual.net> <1bf8c686-8f7f-4ff1-94ff-5ea1a1b1fecd@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net OLk8Q9m6fTLVSjCVSww5/AxWoTpBGPwj3/akJgWTzkJKuYXLCe1CvhQKNXo0yvUWE=
Cancel-Lock: sha1:EsQHh41vDzJXPbSG2nW7h67R7SY=
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
In-Reply-To: <1bf8c686-8f7f-4ff1-94ff-5ea1a1b1fecd@googlegroups.com>
Xref: csiph.com comp.lang.java.programmer:15427

On 18.06.2012 21:28, Lew wrote:
> Robert Klemme wrote:
>> I totally agree.  Btw, there is one interesting detail: JavaDoc of
>> Collections.synchronizedList() and the other synchronized*() methods
>> explicitly state that the mutex used for synchronizing is that of the
>> returned object:
>>
>> http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#synchronizedList%28java.util.List%29
>
> I see no such promise there.

<quote>
It is imperative that the user manually synchronize on the returned list 
when iterating over it:

   List list = Collections.synchronizedList(new ArrayList());
       ...
   synchronized (list) {
       Iterator i = list.iterator(); // Must be in synchronized block
       while (i.hasNext())
           foo(i.next());
   }


Failure to follow this advice may result in non-deterministic behavior.
</quote>

Pardon, my wording was wrong: it's not explicitly stated but it follows 
immediately from the quote.  For me that was "explicit" enough. ;-)

> And in fact it's not true. The source for the 'synchronizedCollection()' family
> of methods reveals that there's a separate field 'mutex' of type 'Object' on
> which the methods synchronize.

Did you see how it's initialized?  It's initialized with this, i.e. the 
wrapper instance.  The field serves the sole purpose to be able to 
synchronize on a parent collection when a dependent collection is 
created (e.g. in 
java.util.Collections.SynchronizedRandomAccessList.subList(int, int)). 
So normally the monitor of the wrapper is used as illustrated by the 
JavaDoc quoted.

>> No such statement is done about Vector.  So while the source code of
>> Vector tells us that the Vector instance is used to synchronize the
>> JavaDoc does not give any guarantee about that and - at least
>> theoretically - Sun/Oracle could change that and synchronize on another
>> instance.
>
> And that would rarely matter, unless a person were adding actions that tried to
> synchronize on the same monitor.

No, it also matters in cases like the example quoted above, i.e. when 
you need to perform multiple operations on the Vector instance: when the 
monitor which the Vector instance uses internally is different from the 
one used for the external synchronization then you do not have thread 
safety.  Depending on the logic anything from inconsistent contents to 
CME can happen.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/