Bug 316276

Description Francois Chouinard 2010-06-09 08:19:49 EDT

The results in the ControlFlow view, the Resources view and the Statistics view are not consistent and not systematically reproducible.

There seems to be a concurrency issue where the events are not consistently read in the same sequence depending on the order of the requests to the back-end.

Some background.

Initially, to keep things simple, requests were serviced in sequence and everything was fine except that "long" requests (i.e. going over the whole set of traces to build indexes, checkpoints, stats, etc) would adversely affect the application responsiveness.

To improve user experiences, 2 performance measures were implemented:

1. Request coalescing, where similar requests are merged to limit repeated back-end accesses. This acts essentially as mux/demux and works fine.

2. Request prioritization into "background" vs. "foreground", where FG requests would pre-empt the BG ones.


For the prioritization, 3 approaches were tried and all of them turned out to be problematic:

a. Use 2 request queues (FG and BG) and have the FG requests pre-empt the BG requests. The tests showed that switching between the requests was confusing for the library and that there was no obvious point where a request could be pre-empted safely using a single trace object (i.e file descriptor).

b. Use 2 independent trace objects to service the corresponding requests. By setting the thread priorities properly, it was possible to make the FG requests perform better. However, this was also confusing for the library and led to inconsistent accesses.

c. Use 1 trace object and 1 prioritized request queue where FG requests were given top priority and BG requests (running at lowest priority) were partitioned into smaller requests before being queued. This affected seriously the performance and turned out to be as unreliable as the other approaches.


All this suggests insufficient synchronization either at the library, the JNI component and/or the trace handler level.