Browse Prior Art Database

Method and Apparatus for Monitoring Data Collection without Synchronization Disclosure Number: IPCOM000012085D
Original Publication Date: 2003-Apr-07
Included in the Prior Art Database: 2003-Apr-07
Document File: 3 page(s) / 10K

Publishing Venue



A program product is disclosed for application monitoring of multi-threaded applications without mutual exclusion that nonetheless provides for arbitrarily high probability of traced event delivery. The core of the technique involves careful implementation of thread-local data structures.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Page 1 of 3

Method and Apparatus for Monitoring Data Collection without Synchronization

   Application monitoring can be conducted by instrumenting critical control- and data-flows with code that generates events. Most monitoring techniques immediately turn these events into increments of counters or additions to accumulators. In multi-threaded environments, these counter/accumulator updates must be treated as critical sections to retain accuracy. Ensuring mutual exclusion by direct means is fairly expensive, and it is common for the accuracy requirement to be relatively loose: eg, if 100 events were observable, then only 90 need be reported. The disclosed method is explained against the backdrop of application monitoring/event counting, but this technique applies to any multi-threaded data collection problem that can tolerate a limited rate of event loss.

The core of the method is careful management of the exposures to event loss, both minimizing the windows of opportunity and the impact of an individual loss event. The core of the method is a technique for navigating to a thread-specific data collection area without using critical sections; once this has been achieved, further updates can occur safely as if a critical section were in fact executing. The following Java class shows the core of a simple embodiment of this navigation technique.

public class EventReceiver {

// a thread to periodically collect the thread-local data into a global summary private static Thread coalescingThread = new Thread() {

                private static final long period = <milliseconds to wait between coalescing thread-local data into summary data>;

public void run() {

MetricsData summary = new MetricsData();

while (true) { sleep( period ); MetricsDataArea[] mda = EventReceiver.swapInNewAreas(); for (int i = 0; i < mda.length; ++i) summary.combine( mda[i].mda ); other periodic activities




// used to signal a detected lost race public static class LosingEventException extends Exception { }

// an association between threads and MetricsData (the thread-local wrapper) public static class MetricsDataArea {

Thread claimant; MetricsData mda;

public MetricsDataArea( Thread claimant ) { this.claimant = claimant; mda = new MetricsData();


Page 2 of 3



           // the currently active data areas public static volatile MetricsDataArea[] dataArea = new MetricsData[ maximumNumberOfThreads ];

// used to find the thread's local data area private static MetricsDataArea locateDataArea() throws LosingEventExceptoin {

Thread curThread = Thread.currentThread(); int hc = curThread.hashCode() % maximumNumberOfThreads;

// look for null slot, or the right data area while ((dataArea[ hc ] != null) && (dataArea[ hc ].claimant != curThread) ) hc = (hc + stepSize) % maximumNumberOfThreads;

// initialize if null if (dataArea[hc] == null) dataArea[hc] = new MetricsDataArea( curThread );

MetricsDataArea mda = dataArea[hc];

// make sure this thread owns the identified slot if ((mda == null) || (mda.claimant !=...