Note that there are some explanatory texts on larger screens.

plurals
  1. POimplementing remove on a ConcurrentMultimap without races
    primarykey
    data
    text
    <p>I've been looking at the problem of writing a concurrent <a href="http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Multimap.html" rel="nofollow noreferrer">Multimap</a>, and I have an implementation backed by the <a href="http://code.google.com/p/guava-libraries/" rel="nofollow noreferrer">Google Guava</a> AbstractSetMultimap and a MapMaker computing map that creates on demand the values-collections as a set view over a ConcurrentHashMap. With some care over the view collections and various wrappers, I think this gets pretty close.</p> <p>The big problem, which has already been <a href="http://code.google.com/p/guava-libraries/issues/detail?id=135#c5" rel="nofollow noreferrer">discussed</a> by <a href="https://stackoverflow.com/questions/985012/concurrent-multimap-put-and-remove/985069#985069">others</a> who <a href="http://javadiaspora.blogspot.com/2009/06/concurrentmultimap-please.html" rel="nofollow noreferrer">have</a> tried this, appears to be that of removing the values-collections from the underlying map when they become empty, without introducing race conditions.</p> <p>A couple of options appear to exist.</p> <ul> <li>leave the empty collections there. This will leak some CHMs, but I believe it to be at least correct.</li> <li>try optimistically to remove the collection when empty and compensate if anything else appears in it. This is full of races and seems intrinsically impossible to fix.</li> <li>synchronise everything on the values-collection, which would at least allow this removal, but at the cost of any concurrency after the initial lookup by key.</li> <li>for a smaller penalty (perhaps, depending on usage patterns?), perhaps synchronise on values-collection creation and removal, need to check whether that covers everything.</li> </ul> <p>Questions:</p> <ul> <li>Does anyone know of any better implementation than this? Can we do better composing bits of MapMaker, or does this need a specialised ConcurrentHashMultimap written from scratch?</li> <li>If it's difficult to improve much on this, is this leak likely to be much of an issue in practice? Notable collections such as java.util.HashMap, juc.ConcurrentHashMap and ArrayDeque do not resize the backing store downwards, and ArrayList does not do so automatically. As long as we clear out the objects, I wonder whether this will matter too much.</li> </ul> <p>Thanks</p> <hr> <p><strong>Edit:</strong> see also <a href="http://groups.google.com/group/guava-discuss/browse_thread/thread/19f100a8c072e55d" rel="nofollow noreferrer">the discussion here</a> on the guava mailing list.</p> <hr> <p><strong>Edit 2:</strong> I've since written this up. Please see <a href="http://code.google.com/p/libjoe/" rel="nofollow noreferrer">this Google code area</a> for an implementation. I would greatly appreciate any feedback from anyone who tries it, there rather than here.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload