[concurrency-interest] synchronization based on a key

Jed Wesley-Smith jwesleysmith at atlassian.com
Sun May 27 21:48:18 EDT 2012


We have an implementation that can be striped according to any arbitrary
function from the key type (say a Long) to a smaller subset of the range
(say 64 elements using a modulo of the hash for instance).

https://labs.atlassian.com/wiki/display/CONCURRENT/ManagedLock

It uses the loaner pattern to avoid requiring clients to try lock /finally
unlock.

It also can use weak references to the actual locks objects, meaning the
memory overhead matches the actual locks in use at the time, at the expense
of constructing the objects as they are required.

Here's the interface:
https://labs.atlassian.com/source/browse/CONCURRENT/trunk/src/main/java/com/atlassian/util/concurrent/ManagedLock.java?hb=true

And the factory for creating an instance is here:
https://labs.atlassian.com/source/browse/CONCURRENT/trunk/src/main/java/com/atlassian/util/concurrent/ManagedLocks.java?hb=true
On 25 May 2012 04:22, Dimitris Andreou <jim.andreou at gmail.com> wrote:

> Yes. Basically you choose a point in the trade-off of "how much memory
> you're willing to spend on lock stripes" vs "how many accidental collisions
> (different keys mapped to the same lock) you can tolerate".
>
> The other option is whether you want to preallocate all locks (and get a
> compact representation for them; viable for small sets of stripes, but not
> if you want millions of them), or allocate them dynamically (needs a
> ConcurrentMap and the overhead is higher)
>
> On Thu, May 24, 2012 at 10:48 AM, bhm <bheem at sbcglobal.net> wrote:
>
>> Thanks.
>>
>> If I understand this correctly, this keeps a collection of lock
>> objects (Lock/Semaphore/ReadWriteLock) and smear method can map
>> multiple keys to same index and
>> so same lock and amount of concurrency is contained by the size of
>> collection of lock objects (eager or lazy)
>>
>> On Thu, May 24, 2012 at 12:13 PM, Dimitris Andreou
>> <jim.andreou at gmail.com> wrote:
>> > http://code.google.com/p/guava-libraries/issues/detail?id=859#c11
>> >
>> > The file attached to the linked comment might end up in guava, and deals
>> > with this very problem.
>> >
>> > On May 24, 2012 7:27 AM, "bhm" <bheem at sbcglobal.net> wrote:
>> >>
>> >> I have a method that needs to be synchronized based on a key passed as
>> >> parameter, that is, for same key multiple threads shouldn't be
>> >> running. Following is what I did--
>> >>
>> >>
>> >> static final ConcurrentMap<String,Boolean> IN_PROGRESS =
>> >>   new ConcurrentHashMap<String,Boolean>();
>> >>
>> >> void foo(String key){
>> >>    if(null == IN_PROGRESS.putIfAbsent(key, Boolean.TRUE)){
>> >>      // no other thread is processing this key
>> >>      try{
>> >>          // process this key
>> >>      } finally {
>> >>         // done with processing this key
>> >>         IN_PROGRESS.remove(key)
>> >>      }
>> >>    } else {
>> >>      // some other thread is running this key, discard it
>> >>    }
>> >> }
>> >>
>> >> this works if I need to discard the request to process the key from
>> >> thread t1 when another thread, t2, is processing that key.
>> >>
>> >> I need help to do following-
>> >> make thread t1 wait while t2 is processing the key and resume t1 when
>> >> t2 is finish processing same key.
>> >>
>> >> I'm aware that if there are multiple threads t1,t3,t4.. etc waiting
>> >> for t2 to finish anyone of these thread can wake up and start
>> >> processing the key irrespective of their order (if there is any) of
>> >> asking to process the key.
>> >>
>> >> Thanks for help.
>> >>
>> >> Bheem
>> >> _______________________________________________
>> >> Concurrency-interest mailing list
>> >> Concurrency-interest at cs.oswego.edu
>> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120528/e0e2fbcc/attachment.html>


More information about the Concurrency-interest mailing list