Use Begin/End semantics for synthetic delays

Use Begin/End semantics for synthetic delays
    
Currently synthetic delays use an Activate/Apply scheme were Activate
can be called several times and a single call to Apply will execute the
delay. Both calls need to happen on the same thread.
    
This patch changes this to a Begin/End model where the delay start point
is designated with Begin and executed with End. Both calls can happen on
any thread for a given delay. Calls can also be nested so that the inner
Begin/End pairs do nothing and only the outermost End will apply the
delay.
    
This change is primarily to make it easier to integrate synthetic delays
to asynchronous tasks such as texture uploads. One only needs to call
Begin for every queued task and then End in each individual tasks to
apply the delay automatically to a "burst" of work.
    
This patch also introduces parallel versions of Begin and End. They are
useful for several applying independent instances of the same delay.
    
We also add a function for resetting all registered synthetic delays.
This is needed for telemetry tests to reset delays to a clean slate
between pages.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=243409

[brianderson, 2013-12-19 00:16:58]

https://codereview.chromium.org/104613003/diff/20001/base/debug/trace_event_s...
File base/debug/trace_event_synthetic_delay.cc (left):

https://codereview.chromium.org/104613003/diff/20001/base/debug/trace_event_s...
base/debug/trace_event_synthetic_delay.cc:22: struct ThreadState {
Since you are removing the thread-local state, does that mean delays of the same
category share state (end times) across threads? Do we not need to worry about
categories being applied independently on separate threads anymore?

https://codereview.chromium.org/104613003/diff/20001/base/debug/trace_event_s...
File base/debug/trace_event_synthetic_delay.cc (right):

https://codereview.chromium.org/104613003/diff/20001/base/debug/trace_event_s...
base/debug/trace_event_synthetic_delay.cc:130: ApplyDelay(end_time);
I like how you make the client worry about about the cross thread handling. It's
much cleaner and more explicit.

[Sami, 2013-12-19 11:14:59]

https://codereview.chromium.org/104613003/diff/20001/base/debug/trace_event_s...
File base/debug/trace_event_synthetic_delay.cc (left):

https://codereview.chromium.org/104613003/diff/20001/base/debug/trace_event_s...
base/debug/trace_event_synthetic_delay.cc:22: struct ThreadState {
On 2013/12/19 00:16:59, Brian Anderson wrote:
> Since you are removing the thread-local state, does that mean delays of the
same
> category share state (end times) across threads? Do we not need to worry about
> categories being applied independently on separate threads anymore?

Yes, now the only way to apply a specific delay independently on several threads
is to use the parallel versions Begin/End. Turns out with the delay points we
have now, there isn't really a need to run them in parallel except in the raster
worker pool. Note that we still need thread safety, e.g., for async texture
uploads where Begin and End are called on different threads.

Now that I think about it, there's a way to make all this a little less
surprising by making the scoped delay (TRACE_EVENT_SYNTHETIC_DELAY) use the
parallel path. This way you can sprinkle the scoped delays pretty much anywhere
and only need to worry about threading for the other variants.

https://codereview.chromium.org/104613003/diff/20001/base/debug/trace_event_s...
File base/debug/trace_event_synthetic_delay.cc (right):

https://codereview.chromium.org/104613003/diff/20001/base/debug/trace_event_s...
base/debug/trace_event_synthetic_delay.cc:130: ApplyDelay(end_time);
On 2013/12/19 00:16:59, Brian Anderson wrote:
> I like how you make the client worry about about the cross thread handling.
It's
> much cleaner and more explicit.

Thanks. It took a few tries to get here but I think the model looks good now :)

[nduca, 2014-01-07 19:13:53]

lgtm

[brianderson, 2014-01-07 19:15:10]

lgtm too

[commit-bot: I haz the power, 2014-01-07 19:53:54]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/skyostil@chromium.org/104613003/80001

[commit-bot: I haz the power, 2014-01-07 22:28:45]

Change committed as 243409