[Bug translator/26296] New: delay script-global locking until required

[Craig Ringer]

>
> IOW: defer locking to the first moment when any global is actually
> read/written, tracking locked-ness in a new context local.  This would
> involve
> only a small change to the translator, involving only context-free logic.
> That
> could later be optimized to remove repeated checks/etc. over multiple
> global vars in
> a control-flow / context aware way.
>
>
Even an explicit construct that scopes locking would be handy. Borrow from
Java's "synchronized" perhaps.

The fact that whole probes get locked is a serious limitation for one of my
systemtap use cases, where I inject delays and faults into the target
application. The probe flow is supposed to be something like:

global targets_map;

probe process("foo").mark("some_probe_point") {
  if (pid() in targets_map) {
      kdelay(100000);
  }
}

where kdelay is a simple embedded C wrapper around the kernel function of
the same name. But due to the locking on the global "targets_map", every
hit on "some_probe_point" will block on the lock held by the sleeping
probe. So probes can't inject sleeps or delays to try to trigger race
conditions.

So yes, the ability to take a lock over a narrower scope than the whole
probe would be very desirable.

I've wondered about the feasibility of doing this in embedded C, but
haven't had a chance to explore it properly yet.

This reminds me - is it ever safe to sleep in a systemtap probe, e.g. to
call ksleep()  rather than busy-loop?

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 2ndQuadrant - PostgreSQL Solutions for the Enterprise