[concurrency-interest] backport: ConcurrentModificationException with take() and contains()?

serwei serwei at gmail.com
Wed Apr 2 23:18:27 EDT 2008


Ho thanks!
I'll go try!

I couldn't supply a version because the file's MANIFEST only stated
the JDK and the Ant version.... and I couldn't find the binary of
matching size lol

On 02/04/2008, concurrency-interest-request at cs.oswego.edu
<concurrency-interest-request at cs.oswego.edu> wrote:
> Send Concurrency-interest mailing list submissions to
>         concurrency-interest at altair.cs.oswego.edu
>
>  To subscribe or unsubscribe via the World Wide Web, visit
>         http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>  or, via email, send a message with subject or body 'help' to
>         concurrency-interest-request at altair.cs.oswego.edu
>
>  You can reach the person managing the list at
>         concurrency-interest-owner at altair.cs.oswego.edu
>
>  When replying, please edit your Subject line so it is more specific
>  than "Re: Contents of Concurrency-interest digest..."
>
>
>  Today's Topics:
>
>    1. Re: Question about reordering and volatile (Jeremy Manson)
>    2. Re: Question about reordering and volatile (Joe Bowbeer)
>    3. Re: Question about reordering and volatile (Jeremy Manson)
>    4. unsubscribe me from this mail group (Madhu Soudathikar)
>    5. Re: Termination of daemon threads (David Holmes)
>    6. backport: ConcurrentModificationException with take() and
>       contains()? (serwei)
>    7. Re: CHM#replace(key, null, newValue) (Dhanji R. Prasanna)
>    8. Re: CHM#replace(key, null, newValue) (Tim Peierls)
>    9. Re: backport: ConcurrentModificationException with take() and
>       contains()? (Holger Hoffst?tte)
>
>
>  ----------------------------------------------------------------------
>
>  Message: 1
>  Date: Tue, 01 Apr 2008 14:06:25 -0700
>  From: Jeremy Manson <jmanson at cs.umd.edu>
>  Subject: Re: [concurrency-interest] Question about reordering and
>         volatile
>  To: Peter Veentjer <alarmnummer at gmail.com>
>  Cc: concurrency-interest <concurrency-interest at cs.oswego.edu>
>  Message-ID: <47F2A3D1.3000200 at cs.umd.edu>
>  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>  "Roach Motel" applies to synchronized blocks -- instructions can move
>  into them, but not out.  So, normal accesses can be moved from after a
>  monitorexit to before it, and from before a monitorenter to after it.
>  That's the roach motel principle.
>
>  The same reasoning applies to volatiles under the assumption that a
>  volatile write is "the same" as a monitorexit and that a volatile read
>  is "the same" as a monitorenter.
>
>  So, your answer is that you *can* move normal accesses that occur after
>  a volatile write to before it.
>
>                                         Jeremy
>
>  Peter Veentjer wrote:
>  > I have a question about reorderings and volatile writes.
>  >
>  > Reorderings and volatile writes follow the 'roach motel'  (just like
>  > synchronized blocks) that prevents instructions from jumping over.
>  >
>  > Allowing an instruction before a volatile write on variable x to jump
>  > over that write, can lead to not seeing the effects of that
>  > instruction when you do the volatile read on x.This is not allowed
>  > according to the JMM: all changes made in thread a when it does a
>  > volatile write on  x, are visible when thread b does a volatile read
>  > on x. Ok.. no problem so far.
>  >
>  > But what about instructions after the volatile write? If these were
>  > allowed (and they are not according to the roach motel principle) to
>  > jump in front of the volatile write of x, thread b could see these
>  > changes as well. The results are exactly the same as the situation
>  > that the read of x (by thread b) happens after the instruction after
>  > the volatile write has executed (by thread a). So the letting the
>  > instruction after the write to (volatile variable) x, in front of this
>  > write, would not cause any havoc.
>  >
>  > So what is the reason that instructions after the volatile write are
>  > not allowed to jump over this volatile write?
>  > _______________________________________________
>  > Concurrency-interest mailing list
>  > Concurrency-interest at altair.cs.oswego.edu
>  > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>  ------------------------------
>
>  Message: 2
>  Date: Tue, 1 Apr 2008 15:23:29 -0700
>  From: "Joe Bowbeer" <joe.bowbeer at gmail.com>
>  Subject: Re: [concurrency-interest] Question about reordering and
>         volatile
>  To: concurrency-interest <concurrency-interest at cs.oswego.edu>
>  Message-ID:
>         <31f2a7bd0804011523i3547ac23v3bb5de4602fefd8e at mail.gmail.com>
>  Content-Type: text/plain; charset="iso-8859-1"
>
>  On Tue, Apr 1, 2008 at 2:06 PM, Jeremy Manson wrote:
>
>  > "Roach Motel" applies to synchronized blocks -- instructions can move
>  > into them, but not out.  So, normal accesses can be moved from after a
>  > monitorexit to before it, and from before a monitorenter to after it.
>  > That's the roach motel principle.
>  >
>  > The same reasoning applies to volatiles under the assumption that a
>  > volatile write is "the same" as a monitorexit and that a volatile read
>  > is "the same" as a monitorenter.
>  >
>  > So, your answer is that you *can* move normal accesses that occur after
>  > a volatile write to before it.
>  >
>  >
>  Jeremy,
>
>  Is it wrong or misleading for the FAQ to say:
>
>  "Under the new memory model, accesses to volatile variables cannot be
>  reordered with each other or nonvolatile variable accesses."
>
>   http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile
>
>  I'd interpret that to mean that nothing can jump over a volatile access in
>  either direction...
>
>  By the way, the FAQ does later clarify that without a matching read, the
>  volatile write doesn't happen-before anything, which suggests that unread
>  volatile writes can be elided.
>
>  --Joe
>  -------------- next part --------------
>  An HTML attachment was scrubbed...
>  URL: /pipermail/attachments/20080401/7ab63c06/attachment-0001.html
>
>  ------------------------------
>
>  Message: 3
>  Date: Tue, 01 Apr 2008 15:37:50 -0700
>  From: Jeremy Manson <jmanson at cs.umd.edu>
>  Subject: Re: [concurrency-interest] Question about reordering and
>         volatile
>  To: Joe Bowbeer <joe.bowbeer at gmail.com>
>  Cc: concurrency-interest <concurrency-interest at cs.oswego.edu>
>  Message-ID: <47F2B93E.8030605 at cs.umd.edu>
>  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>  Joe Bowbeer wrote:
>  > Jeremy,
>  >
>  > Is it wrong or misleading for the FAQ to say:
>  >
>  > "Under the new memory model, accesses to volatile variables cannot be
>  > reordered with each other or nonvolatile variable accesses."
>  >
>  >   http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile
>  >
>  > I'd interpret that to mean that nothing can jump over a volatile access
>  > in either direction...
>  >
>  > By the way, the FAQ does later clarify that without a matching read, the
>  > volatile write doesn't happen-before anything, which suggests that
>  > unread volatile writes can be elided.
>
>  Let's go with "misleading" FTW.  That sentence was more intended to draw
>  a contrast with the way things used to be.  The following sentence is
>  the more accurate one.
>
>  I'll fix it.
>
>                                         Jeremy
>
>
>  ------------------------------
>
>  Message: 4
>  Date: Tue, 1 Apr 2008 16:08:00 -0700 (PDT)
>  From: Madhu Soudathikar <sv_madhuraj at yahoo.com>
>  Subject: [concurrency-interest] unsubscribe me from this mail group
>  To: Concurrency-interest at cs.oswego.edu
>  Message-ID: <404019.3700.qm at web33401.mail.mud.yahoo.com>
>  Content-Type: text/plain; charset="us-ascii"
>
>
>
>
>       ____________________________________________________________________________________
>  You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.
>  http://tc.deals.yahoo.com/tc/blockbuster/text5.com
>  -------------- next part --------------
>  An HTML attachment was scrubbed...
>  URL: /pipermail/attachments/20080401/6f8cbbbf/attachment-0001.html
>
>  ------------------------------
>
>  Message: 5
>  Date: Wed, 2 Apr 2008 10:41:48 +1000
>  From: "David Holmes" <dcholmes at optusnet.com.au>
>  Subject: Re: [concurrency-interest] Termination of daemon threads
>  To: "Peter Kovacs" <peter.kovacs.1.0rc at gmail.com>
>  Cc: concurrency-interest at cs.oswego.edu
>  Message-ID: <NFBBKALFDCPFIDBNKAPCCECAHLAA.dcholmes at optusnet.com.au>
>  Content-Type: text/plain;       charset="us-ascii"
>
>  Peter,
>
>  "critical" in this context means "anything you'd be upset about if it didn't
>  get done" - which implies it's something visible outside the current
>  incarnation of the VM, such as writing a log file, updating a database, ...
>
>  If you create a daemon thread then you need to be prepared for it being
>  abruptly terminated when your application ends (by which I mean voluntarily
>  not by being killed externally :) )
>
>  Cheers,
>  David Holmes
>
>  > -----Original Message-----
>  > From: concurrency-interest-bounces at cs.oswego.edu
>  > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Peter
>  > Kovacs
>  > Sent: Tuesday, 1 April 2008 7:43 PM
>  > To: dholmes at ieee.org
>  > Cc: concurrency-interest at cs.oswego.edu
>  > Subject: Re: [concurrency-interest] Termination of daemon threads
>  >
>  >
>  > David,
>  >
>  > I wonder what "critical" may mean here. The process is going to be
>  > terminated: resources are freed, memory recovered, locks released...
>  > Nature is at work here making room for a new life... What is critical
>  > for me (e.g. a big salary raise, dating with the handsome assistant
>  > from the 99th floor) will not be critical after my death. In other
>  > words: what can be critical as I am just dying.
>  >
>  > OK, I try to put my egotism aside: may "critical" mean "something"
>  > which other processes rely on? Should the answer then not be: a daemon
>  > thread can do anything, just be prepared for it being abruptly
>  > terminated? Just as if the process itself would be killed -- I assume.
>  > So the advice goes: don't do anything critical in non-daemon threads
>  > either, because your process may get killed. :-)
>  >
>  > Peter
>  >
>  > On Tue, Apr 1, 2008 at 6:41 AM, David Holmes
>  > <dcholmes at optusnet.com.au> wrote:
>  > > A daemon thread should never do anything critical. Daemon threads just
>  > >  "vanish" when the process is terminated. Though for Sun's VM
>  > they are at
>  > >  least brought to a system "safe-point" first - though
>  > executing native code
>  > >  is considered being at a "safe-point" ie outside of the VM.
>  > >
>  > >  It probably could be documented better.
>  > >
>  > >  David Holmes
>  > >
>  > >
>  > >
>  > >  > -----Original Message-----
>  > >  > From: concurrency-interest-bounces at cs.oswego.edu
>  > >  > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf
>  > Of Dimitris
>  > >  > Andreou
>  > >  > Sent: Tuesday, 1 April 2008 2:02 PM
>  > >  > To: concurrency-interest at cs.oswego.edu
>  > >  > Subject: [concurrency-interest] Termination of daemon threads
>  > >  >
>  > >  >
>  > >  > Hi all,
>  > >  >
>  > >  > Here is my question: How are daemon threads terminated? What
>  > if they are
>  > >  > in the middle of a critical operation, like writing to a
>  > file? They seem
>  > >  > to exit immediately. How could that be safe? Or a daemon
>  > thread should
>  > >  > never do anything critical, but always delegate such work to a
>  > >  > non-daemon thread? If any case, shouldn't it be documented in
>  > >  > java.lang.Thread?
>  > >  >
>  > >  > Thanks
>  > >  > Dimitris Andreou
>  > >  >
>  > >  > _______________________________________________
>  > >  > Concurrency-interest mailing list
>  > >  > Concurrency-interest at altair.cs.oswego.edu
>  > >  > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>  > >  >
>  > >
>  > >  _______________________________________________
>  > >  Concurrency-interest mailing list
>  > >  Concurrency-interest at altair.cs.oswego.edu
>  > >  http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>  > >
>  > _______________________________________________
>  > Concurrency-interest mailing list
>  > Concurrency-interest at altair.cs.oswego.edu
>  > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>  ------------------------------
>
>  Message: 6
>  Date: Wed, 2 Apr 2008 16:42:51 +0800
>  From: serwei <serwei at gmail.com>
>  Subject: [concurrency-interest] backport:
>         ConcurrentModificationException with take() and contains()?
>  To: concurrency-interest at cs.oswego.edu
>  Message-ID:
>         <fdda32c0804020142j649ef636y3c7a4d5a3494015b at mail.gmail.com>
>  Content-Type: text/plain; charset=UTF-8
>
>  Hi there,
>
>  is it a confirmed scenario where a ConcurrentModificationException
>  will happen when a DelayQueue.contains() is running and a
>  DelayQueue.take() happens then?
>
>  So I have to manually synchronized (something) for the two?
>
>  Thanks!
>
>  PS: stack below
>
>  java.util.ConcurrentModificationException
>         at edu.emory.mathcs.backport.java.util.PriorityQueue$Itr.checkForComodification(PriorityQueue.java(Inlined
>  Compiled Code))
>         at edu.emory.mathcs.backport.java.util.PriorityQueue$Itr.next(PriorityQueue.java(Compiled
>  Code))
>         at edu.emory.mathcs.backport.java.util.concurrent.DelayQueue$Itr.next(DelayQueue.java(Compiled
>  Code))
>         at java.util.AbstractCollection.contains(AbstractCollection.java(Compiled
>  Code))
>
>
>  ------------------------------
>
>  Message: 7
>  Date: Wed, 2 Apr 2008 17:42:26 +0530
>  From: "Dhanji R. Prasanna" <dhanji at gmail.com>
>  Subject: Re: [concurrency-interest] CHM#replace(key, null, newValue)
>  To: "Peter Veentjer" <alarmnummer at gmail.com>
>  Cc: concurrency-interest <concurrency-interest at cs.oswego.edu>,
>         Matthias Ernst <matthias at mernst.org>
>  Message-ID:
>         <aa067ea10804020512w4c18007fq770a522e4b558930 at mail.gmail.com>
>  Content-Type: text/plain; charset="iso-8859-1"
>
>  On Tue, Apr 1, 2008 at 8:44 PM, Peter Veentjer <alarmnummer at gmail.com>
>  wrote:
>
>  > It is a shame that the value to be placed in the hashmap can't be
>  > created lazy.
>
>
>  You could use a Future<T>. I think there was a thread some time ago
>  discussing this (about a CHM.putIfAbsent(Callable)). The Future<T> was
>  crazybob's idea on that thread.
>
>  Dhanji.
>  -------------- next part --------------
>  An HTML attachment was scrubbed...
>  URL: /pipermail/attachments/20080402/d7578df1/attachment-0001.html
>
>  ------------------------------
>
>  Message: 8
>  Date: Wed, 2 Apr 2008 08:55:43 -0400
>  From: "Tim Peierls" <tim at peierls.net>
>  Subject: Re: [concurrency-interest] CHM#replace(key, null, newValue)
>  To: concurrency-interest <concurrency-interest at cs.oswego.edu>
>  Message-ID:
>         <63b4e4050804020555tbff707ne439fd9256f363bb at mail.gmail.com>
>  Content-Type: text/plain; charset="iso-8859-1"
>
>  Maybe it's time to recycle Doug Lea's post on lazy initialization of map
>  values one more time. I've posted it on the Java Concurrency Wiki:
>
>  http://artisans-serverintellect-com.si-eioswww6.com/default.asp?W122
>
>  --tim
>
>  On Wed, Apr 2, 2008 at 8:12 AM, Dhanji R. Prasanna <dhanji at gmail.com> wrote:
>
>  >
>  >
>  > On Tue, Apr 1, 2008 at 8:44 PM, Peter Veentjer <alarmnummer at gmail.com>
>  > wrote:
>  >
>  > > It is a shame that the value to be placed in the hashmap can't be
>  > > created lazy.
>  >
>  >
>  > You could use a Future<T>. I think there was a thread some time ago
>  > discussing this (about a CHM.putIfAbsent(Callable)). The Future<T> was
>  > crazybob's idea on that thread.
>  >
>  > Dhanji.
>  >
>  -------------- next part --------------
>  An HTML attachment was scrubbed...
>  URL: /pipermail/attachments/20080402/51edd555/attachment-0001.html
>
>  ------------------------------
>
>  Message: 9
>  Date: Wed, 02 Apr 2008 15:32:56 +0200
>  From: Holger Hoffst?tte <holger at wizards.de>
>  Subject: Re: [concurrency-interest] backport:
>         ConcurrentModificationException with take() and contains()?
>  To: concurrency-interest at cs.oswego.edu
>  Message-ID: <47F38B08.9010303 at wizards.de>
>  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>  serwei wrote:
>  > is it a confirmed scenario where a ConcurrentModificationException
>  > will happen when a DelayQueue.contains() is running and a
>  > DelayQueue.take() happens then?
>
>  That seems wrong. Which version of the backport are you using? Looks like
>  an older version. I ask because..
>
>  > So I have to manually synchronized (something) for the two?
>  >
>  > Thanks!
>  >
>  > PS: stack below
>  >
>  > java.util.ConcurrentModificationException
>  >         at edu.emory.mathcs.backport.java.util.PriorityQueue$Itr.checkForComodification(PriorityQueue.java(Inlined
>  > Compiled Code))
>  >         at edu.emory.mathcs.backport.java.util.PriorityQueue$Itr.next(PriorityQueue.java(Compiled
>  > Code))
>  >         at edu.emory.mathcs.backport.java.util.concurrent.DelayQueue$Itr.next(DelayQueue.java(Compiled
>  > Code))
>  >         at java.util.AbstractCollection.contains(AbstractCollection.java(Compiled
>  > Code))
>
>  ..looking at this stack trace it seems that the DelayQueue Iterator
>  directly accesses the internal PriorityQueue without locking, however that
>  is not what's happening in JDK6 or the latest backport (3.1), where the
>  inherited contains() iterates over an unshared array snapshot.
>
>  Ah yes - this is the old (exception-throwing aka non-concurrent) behaviour
>  in JDK5 as implemented by backport 2.x. So the easiest way to fix your
>  problem is simply using the latest backport lib. That's a good idea anyway. :)
>
>  Holger
>
>
>  ------------------------------
>
>  _______________________________________________
>  Concurrency-interest mailing list
>  Concurrency-interest at altair.cs.oswego.edu
>  http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>  End of Concurrency-interest Digest, Vol 39, Issue 4
>  ***************************************************
>


-- 
"Dusting it off..."
http://serwei.deviantart.com


More information about the Concurrency-interest mailing list