From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 884CA3851C19; Fri, 24 Jul 2020 14:12:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 884CA3851C19 From: "arkady.miasnikov at gmail dot com" To: systemtap@sourceware.org Subject: [Bug translator/26296] delay script-global locking until required Date: Fri, 24 Jul 2020 14:12:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: translator X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: arkady.miasnikov at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: systemtap@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Systemtap mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 14:12:47 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26296 --- Comment #2 from arkady.miasnikov at gmail dot com --- On Fri, Jul 24, 2020 at 8:23 AM Craig Ringer 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 logi= c. > > 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, --=20 You are receiving this mail because: You are the assignee for the bug.=