[concurrency-interest] Thread-safety of hasMoreElements() of Vector

Praveen Kumar Jha javapk at gmail.com
Tue Jul 24 11:19:33 EDT 2012


Hi,

Sorry for responding late. Please find my response(s) inline below:


> Date: Thu, 19 Jul 2012 09:11:15 -0700
> From: Joe Bowbeer <joe.bowbeer at gmail.com>
> To: concurrency-interest <concurrency-interest at cs.oswego.edu>
> Subject: Re: [concurrency-interest] Thread-safety of hasMoreElements()
> 	of	Vector

>
> The Enumeration API is not suitable for multi-threaded use because there is
> a window for change between the hasMoreElements call and the subsequent
> nextElement call.
>
> In almost all cases the Enumeration is consumed in the same thread in which
> it is produced.
>
> The strange corner case that you envision is: one thread creates an
> Enumeration and hands it to another thread.  The other thread calls
> hasNextElement and may see a stale value for elementCount, causing it to
> end too early (not calling nextElement) or to fail unexpectedly when it
> does call nextElement.
>
> With this scenario in mind, using "synchronized" in hasMoreElements is more
> correct, though in practice I doubt it will make any difference.
>
> Joe
-------------------------
> Date: Thu, 19 Jul 2012 12:40:16 -0400
> From: Yuval Shavit <yshavit at akiban.com>
> To: Joe Bowbeer <joe.bowbeer at gmail.com>
> Cc: concurrency-interest <concurrency-interest at cs.oswego.edu>

>
> It seems like it's more problematic than that. Vector.elementCount isn't
> volatile, so if you create an Enumeration (and keep it thread-local), but
> the backing Vector changes on some other thread, hasMoreElements() is
> broken. I think that method needs to be synchronized on Vector.this.
>
> ----------------------
> Date: Thu, 19 Jul 2012 09:56:04 -0700
> From: Joe Bowbeer <joe.bowbeer at gmail.com>
> To: concurrency-interest <concurrency-interest at cs.oswego.edu>

>
> If the backing vector is changing on some other thread then Enumeration is
> not a suitable API.  (This is probably the logic applied by the implementer
> who decided not to bother sync'ing hasMoreElements.)
>
> On Thu, Jul 19, 2012 at 9:40 AM, Yuval Shavit wrote:
>



But if that is the case then why is 'Vector.this' synchronized in
nextElement() method?
As I understand, the behavior of both hasMoreElements() and
nextElement() should be on the same lines as far as use of Enumeration
in multithreaded case is concerned. And, I am considering the case
when a thread is reading Vector using Enumeration while other thread
is mutating it.





> Date: Thu, 19 Jul 2012 11:58:55 -0500
> From: Gregg Wonderly <gregg at cytetech.com>
> To: Yuval Shavit <yshavit at akiban.com>
> Cc: Joe Bowbeer <joe.bowbeer at gmail.com>,	concurrency-interest
> 	<concurrency-interest at cs.oswego.edu>
> Subject: Re: [concurrency-interest] Thread-safety of hasMoreElements()
> 	of Vector
> Message-ID: <50083CCF.20005 at cytetech.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 7/19/2012 11:40 AM, Yuval Shavit wrote:
>> It seems like it's more problematic than that. Vector.elementCount isn't
>> volatile, so if you create an Enumeration (and keep it thread-local), but
>> the
>> backing Vector changes on some other thread, hasMoreElements() is broken.
>> I
>> think that method needs to be synchronized on Vector.this.
>
> If you do
>
> while (true) {
> 	boolean more;
> 	synchronized(vector) {
> 		more = vector.hasMoreElements();
> 	}
> 	if( !more) break;
>
> 	...
>
> }




If I have to synchronize over "vector" for hasMoreElements() then I
can do it for nextElement() method too while enumerating, so then why
is nextElement() synchronizing over 'Vector.this'. Shouldn't it be
left for the clients of Vector to synchronize it manually while
enumerating?




>
> Then you can "synchronize" with the state of other threads, obviously.  But
> it
> definitely looks like it's broken for that use case.  One could argue, that
> it
> would not be very productive for two threads to use an instance in this
> mode,
> without some other "happens-before" going on anyway.  For example, if you
> have a
> thread adding elements and another processing them, there should be a
> semaphore
> of some sort.  I would really be surprised to find code that used an
> instance
> without some other happens-before relationship between the two threads,
> which
> would cause the value to be correct.
>
> Gregg


More information about the Concurrency-interest mailing list