// Copyright (c) 2011 The Chromium Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
#ifndef CHROME_BROWSER_METRICS_HISTOGRAM_SYNCHRONIZER_H_
#define CHROME_BROWSER_METRICS_HISTOGRAM_SYNCHRONIZER_H_
#pragma once
#include <string>
#include <vector>
#include "base/basictypes.h"
#include "base/memory/ref_counted.h"
#include "base/synchronization/condition_variable.h"
#include "base/synchronization/lock.h"
#include "base/time.h"
class MessageLoop;
class Task;
// This class maintains state that is used to upload histogram data from the
// various renderer processes, into the browser process. Such transactions are
// usually instigated by the browser. In general, a renderer process will
// respond by gathering snapshots of all internal histograms, calculating what
// has changed since its last upload, and transmitting a pickled collection of
// deltas.
//
// There are actually two modes of update request. One is synchronous (and
// blocks the UI thread, waiting to populate an about:histograms tab) and the
// other is asynchronous, and used by the metrics services in preparation for a
// log upload.
//
// To assure that all the renderers have responded, a counter is maintained (for
// each mode) to indicate the number of pending (not yet responsive) renderers.
// To avoid confusion about a response (i.e., is the renderer responding to a
// current request for an update, or to an old request for an update) we tag
// each group of requests with a sequence number. When an update arrives we can
// ignore it (relative to the counter) if it does not relate to a current
// outstanding sequence number.
//
// There is one final mode of use, where a renderer spontaneously decides to
// transmit a collection of histogram data. This is designed for use when the
// renderer is terminating. Unfortunately, renders may be terminated without
// warning, and the best we can do is periodically acquire data from a tab, such
// as when a page load has completed. In this mode, the renderer uses a
// reserved sequence number, different from any sequence number that might be
// specified by a browser request. Since this sequence number can't match an
// outstanding sequence number, the pickled data is accepted into the browser,
// but there is no impact on the counters.
class HistogramSynchronizer : public
base::RefCountedThreadSafe<HistogramSynchronizer> {
public:
enum RendererHistogramRequester {
ASYNC_HISTOGRAMS,
SYNCHRONOUS_HISTOGRAMS
};
// Construction also sets up the global singleton instance. This instance is
// used to communicate between the IO and UI thread, and is destroyed only
// as the main thread (browser_main) terminates, which means the IO thread has
// already completed, and will not need this instance any further.
HistogramSynchronizer();
~HistogramSynchronizer();
// Return pointer to the singleton instance, which is allocated and
// deallocated on the main UI thread (during system startup and teardown).
static HistogramSynchronizer* CurrentSynchronizer();
// Contact all renderers, and get them to upload to the browser any/all
// changes to histograms. Return when all changes have been acquired, or when
// the wait time expires (whichever is sooner). This method is called on the
// main UI thread from about:histograms.
void FetchRendererHistogramsSynchronously(base::TimeDelta wait_time);
// Contact all renderers, and get them to upload to the browser any/all
// changes to histograms. When all changes have been acquired, or when the
// wait time expires (whichever is sooner), post the callback_task to the
// specified thread. Note the callback_task is posted exactly once.
static void FetchRendererHistogramsAsynchronously(
MessageLoop* callback_thread, Task* callback_task, int wait_time);
// This method is called on the IO thread. Deserializes the histograms and
// records that we have received histograms from a renderer process.
static void DeserializeHistogramList(
int sequence_number, const std::vector<std::string>& histograms);
private:
// Establish a new sequence_number_, and use it to notify all the renderers of
// the need to supply, to the browser, any changes in their histograms.
// The argument indicates whether this will set async_sequence_number_ or
// synchronous_sequence_number_.
// Return the sequence number that was used.
int NotifyAllRenderers(RendererHistogramRequester requester);
// Records that we are waiting for one less histogram from a renderer for the
// given sequence number. If we have received a response from all renderers,
// either signal the waiting process or call the callback function.
void DecrementPendingRenderers(int sequence_number);
// Set the callback_thread_ and callback_task_ members. If these members
// already had values, then as a side effect, post the old callback_task_ to
// the old callaback_thread_. This side effect should not generally happen,
// but is in place to assure correctness (that any tasks that were set, are
// eventually called, and never merely discarded).
void SetCallbackTaskAndThread(MessageLoop* callback_thread,
Task* callback_task);
void ForceHistogramSynchronizationDoneCallback(int sequence_number);
// Gets a new sequence number to be sent to renderers from browser process and
// set the number of pending responses for the given type to renderer_count.
int GetNextAvailableSequenceNumber(RendererHistogramRequester requster,
int renderer_count);
// Internal helper function, to post task, and record callback stats.
void InternalPostTask(MessageLoop* thread, Task* task,
int unresponsive_renderers, const base::TimeTicks& started);
// This lock_ protects access to all members.
base::Lock lock_;
// This condition variable is used to block caller of the synchronous request
// to update histograms, and to signal that thread when updates are completed.
base::ConditionVariable received_all_renderer_histograms_;
// When a request is made to asynchronously update the histograms, we store
// the task and thread we use to post a completion notification in
// callback_task_ and callback_thread_.
Task* callback_task_;
MessageLoop* callback_thread_;
// We don't track the actual renderers that are contacted for an update, only
// the count of the number of renderers, and we can sometimes time-out and
// give up on a "slow to respond" renderer. We use a sequence_number to be
// sure a response from a renderer is associated with the current round of
// requests (and not merely a VERY belated prior response).
// All sequence numbers used are non-negative.
// last_used_sequence_number_ is the most recently used number (used to avoid
// reuse for a long time).
int last_used_sequence_number_;
// The sequence number used by the most recent asynchronous update request to
// contact all renderers.
int async_sequence_number_;
// The number of renderers that have not yet responded to requests (as part of
// an asynchronous update).
int async_renderers_pending_;
// The time when we were told to start the fetch histograms asynchronously
// from renderers.
base::TimeTicks async_callback_start_time_;
// The sequence number used by the most recent synchronous update request to
// contact all renderers.
int synchronous_sequence_number_;
// The number of renderers that have not yet responded to requests (as part of
// a synchronous update).
int synchronous_renderers_pending_;
// This singleton instance should be started during the single threaded
// portion of main(). It initializes globals to provide support for all future
// calls. This object is created on the UI thread, and it is destroyed after
// all the other threads have gone away. As a result, it is ok to call it
// from the UI thread (for UMA uploads), or for about:histograms.
static HistogramSynchronizer* histogram_synchronizer_;
DISALLOW_COPY_AND_ASSIGN(HistogramSynchronizer);
};
#endif // CHROME_BROWSER_METRICS_HISTOGRAM_SYNCHRONIZER_H_