FW: locking timeout error ?

[Stone, Joshua I]

Frank Ch. Eigler wrote:
>> [...] Imagine the performance if the probe handles perhaps 5
>> different locks in its body, which is well within reason.
> 
> If the locking scheme is reorganized as outlined in #2060, by pulling
> all lock/unlock operations to the outermost level of a probe, then the
> overall (rather than per-lock) timeout could be easily bounded.  Plus
> each global variable would be locked at most once per probe handler
> run, rather than around each appearance in an expression.

I really like this idea, because it treats probes as truly atomic - if
you don't get all of the locks you need, don't do anything.
Implementing this will also require full function analysis to propogate
the locks back to the probe.

> Actually, even without that, we could accumulate locking iteration
> counts in a new context variable, and limit the cumulative (rather
> than individual) total to MAXTRYLOCK.

I think this would be a much more meaningful metric, and it should be an
easy thing to implement...


Josh