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

Praveen Kumar Jha javapk at gmail.com
Tue Jul 24 23:59:30 EDT 2012


Hi,

Thank you, and thanks to all the responders for their valuable response.

Regards,
Praveen


On Wed, Jul 25, 2012 at 12:30 AM, Gregg Wonderly <gergg at cox.net> wrote:

>
> On Jul 24, 2012, at 10:19 AM, Praveen Kumar Jha wrote:
>
> > 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.
>
> I'm not stating that this is correct, just indicating a way to make it
> work correctly.  The bigger issue is the use case that seems to be driving
> your question.  If you are inserting in one thread, and enumerating in
> another, then it would be better to use a completely different kind of data
> structure it would seem.  If the inserts and removals are random, a Map
> might be a better interface.  If they are FIFO or LIFO as Mike said, then a
> different kind of list, queue or stack, might be better.  Any time you have
> two threads implementing the worker pattern, you need some point of
> rendezvous anyway.  It is that "happens before" relationship, around that
> rendezvous, which would make hasMoreElements() work, if you did use it.
>
> Gregg Wonderly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120725/25a267b6/attachment.html>


More information about the Concurrency-interest mailing list