[concurrency-interest] new monitoring and manaement support for custom synchronizers

Doug Lea dl at cs.oswego.edu
Mon Apr 25 07:36:03 EDT 2005

For Mustang, we are putting in better support for integrating custom
locks and synchronizers with the Java monitoring and management
(M&M) framework. This entails a few changes to the classes underlying
ReentrantLock etc. We'd like to know if any of you have any comments
or suggestions.

The basic idea is that you'd like to have M&M tools
to have access to two kinds of information:

1. For any blocked thread, the synchronization object
responsible for it blocking.

2. For any lock/synchronizer, the thread that is impeding
other threads from acquiring it -- normally the "owner"
of a lock.

So, there are two sides of added support:

1. There are now overloaded forms of park, parkNanos, and
    parkUntil in LockSupport that take an "Object blocker"
    argument and record this as a per-thread attribute
    as long as the calling thread is blocked in park.
    Plus a new method getBlocker(Thread t) to access this
    object. The blocker argument can be anything at all
    (normally "this" of a synchronization object). M&M
    tools may then include specialized support for certain
    kinds of blocker objects (like the ones used in JSR166
    locks), and maybe customizable support for others defined
    by users.

2. Classes AbstractQueuedSynchronizer and the new
    Mustang addition AbstractQueuedLongSynchronizer are
    now subclasses of the simple class AbstractOwnableSynchronizer.
    AbstractOwnableSynchronizer contains only two methods
    getExclusiveOwnerThread and setExclusiveOwnerThread that
    get/set an internal "owner" field. This raises up
    similar fields that were in subclasses for JSR166 locks
    so that they can be uniformly accessed by tools -- this
    way tools don't need to know about the details of
    internal inner helper classes within locks in order to
    find the threads that are causing others to block.
    Synchronizers that do not have any notion of exclusive
    ownership don't have to use this field at all (in which
    case ownership-tracing tools cannot help diagnose
    blockages anyway).

So far, it looks like these changes don't noticeably
affect performance of synchronizers.

Note that this support only enables new monitoring and diagnostics;
they don't yet exist. But I believe that people will be working on
extensions to M&M tools soon to exploit these capabilities.


More information about the Concurrency-interest mailing list