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

[arkady.miasnikov at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26296

--- Comment #2 from arkady.miasnikov at gmail dot com ---
On Fri, Jul 24, 2020 at 8:23 AM Craig Ringer <craig@2ndquadrant.com> wrote:
>
> >
> > 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);
>   }
> }

Usually there is a  lock because of the use of maps/associative
arrays. Use your own C implementation (check the code base I sent you)
... or we can implement inline C support.

You can not sleep in many probes. Such code does not crash
immediately, but eventually it will.
In some probes it is safe to sleep.

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

That's the route you have

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

Spinlocks are Ok. Calls to sleep() generally is not safe,

-- 
You are receiving this mail because:
You are the assignee for the bug.