From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by sourceware.org (Postfix) with ESMTPS id 3AF18382E04F for ; Fri, 24 Jul 2020 05:22:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3AF18382E04F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=2ndquadrant.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=craig.ringer@2ndquadrant.com Received: by mail-lj1-x22a.google.com with SMTP id d17so8712212ljl.3 for ; Thu, 23 Jul 2020 22:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GrcPNNUf58jk/ej3U2rma8z4GqOAB0bE8GAuACA11M0=; b=PBiFJNsJi7UGM7gTpanrH8XCofXAlh6LWIsDYgWP7px3f4jfeDKcl9hnNCfVpaqHRX Cx6Xj1iiA0BmwYOYrCVXz/HeQ3qBe4Y6JCN7/pxS1bkzfWzPAUM7b+k9sR8MZsJS+64f z2JOJIR6XnzU8FaiHfgx6F9ZkaUgFHDVU/CH899ddQc3jHU062puQZP+HYZTWKJ1xr2u o2tA+7Vx4HS457bVmZ+AwbG08yX/GgokEzojCpgP2iGM6zd09U4pGznnpl8GpO2jplvb 0j/eM0cj0AgxpUlIZqEjxgwxV3uVZQn+7CZoukpLfMR3jG5NM7JPGCle8RvOxktnwK5L c7Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GrcPNNUf58jk/ej3U2rma8z4GqOAB0bE8GAuACA11M0=; b=MOJ+e7U/M9Q+r3S0IiJltHsBPlqcnh+rj2cxCgFhCRpM/70L8sQhEmT8HjIfyGBeae nmVsvfVVdnu1yWbmU2gKVSn1ik2OKIA8mz8aA2lRmnhS01RTNeVJaPm0XsRSunx2oNlg 1X97ekKoavC0iRlSm6iToXyEz59IKxjkGQ4X7HmFQjoIYKGbrCX+3T6zzjp4+YCwMPU7 z2dTQ1fOqxpWBbzyqCY3dZT8r2l2zaHWvO64EhohJ/zMeob9ZaUoEQ4KSf02abLn+f6J OIdZTN2ABGCMrCxn4oYR2+uAFkFA++RGfpSpGVpl+rAtTT0tu+kW7OvLvHjt431xEJYd XpFg== X-Gm-Message-State: AOAM530M8sImx7dtQ9sHRF5/nDSwXLbCvLcBwCUH+whg8b2sXiA4+mnI jTsUhm6dq/gS/kg+QgonnifsJDxoEXcNFaZAyvIZZAOZ X-Google-Smtp-Source: ABdhPJybw/qT8eo9KB+u3g/Cr42Ig0c1DBPG1SHKZBQVapcEz7CUfxbHnF+vUOxkYKqF/lIo+F9qA13f9NxF3jGsIvE= X-Received: by 2002:a05:651c:231:: with SMTP id z17mr3370260ljn.163.1595568160806; Thu, 23 Jul 2020 22:22:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Craig Ringer Date: Fri, 24 Jul 2020 13:22:29 +0800 Message-ID: Subject: Re: [Bug translator/26296] New: delay script-global locking until required To: fche at redhat dot com Cc: systemtap@sourceware.org X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 05:22:45 -0000 > > 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