[concurrency-interest] Problem with using an unbounded map of Mutex lock objects

Dhanji R. Prasanna dhanji at gmail.com
Sat Jun 3 01:04:25 EDT 2006


>
> I'm not quite sure what you have in mind for pooling locks, but I think
> it was a requirement that all operations for key K use the same lock,
> which eliminates pooling as an option.
>

I wasnt very clear before: pool the locks and then rotate them behind
the stripes (making sure the same hashcode is not in use). That way an
idle stripe doesnt (always) equal an idle lock. It's a bit complex to
track in-use hashkeys, but..

private synchronized Mutex getLockForKey(final Serializable key) {
    int h = key.hashCode() % N;

    if (h < 0)
        h += N;

    Mutex m = stripes[h].getLockInUse(key.hashCode());
    if (null != m)
       return m;

    stripes[h].use(pool.pop(), key.hashCode());
    return stripes[h].getLockInUse(key.hashCode());
}

private synchronized void releaseLock(final Serializable key) {
    int h = key.hashCode() % N;

    if (h < 0)
        h += N;

    try {
       pool.push(stripes[h].getLockInUse(key.hashCode()));
       stripes[h].unuse(key.hashCode());
    } catch (NPE) {
        throw new LockWasNotInUseException();
    }
}

does this seem viable?
purely pooling locks (without the stripes) for each key sets up a
chicken and egg condition with 'how do we get synchronized access to
the in-use locks', I agree, it's not even near feasible.  =)


More information about the Concurrency-interest mailing list