FW: locking timeout error ?

[Martin Hunt]

On Mon, 2006-01-16 at 15:50 -0500, Frank Ch. Eigler wrote:
> 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.

If you reorganize the locks as proposed, you should be able to actually
reduce MAXTRYLOCK because the consequences of a lock timeout will simply
be an increment of the skipped probe counter instead of a fatal error.
Maps are not scalable anyway and pmaps will be unaffected, so I expect
performance will not suffer at all.

Martin