Re: FW: locking timeout error ?

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

> [...] 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.

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.


> Perhaps the better way to approach this is to estimate how long we might
> expect the person holding the lock to take.  Do we have any
> microbenchmarks on how long various operations take, like indexing a
> map?

Unfortunately, no.  Bug #1884 and #2060 could benefit from the
development of a microbenchmark suite.


- FChE