From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4284 invoked by alias); 20 Nov 2009 21:25:20 -0000 Received: (qmail 4210 invoked by uid 48); 20 Nov 2009 21:25:09 -0000 Date: Fri, 20 Nov 2009 21:25:00 -0000 Message-ID: <20091120212509.4209.qmail@sourceware.org> From: "jistone at redhat dot com" To: systemtap@sources.redhat.com In-Reply-To: <20091006202043.10741.jistone@redhat.com> References: <20091006202043.10741.jistone@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug translator/10741] Merge tandem locks X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q4/txt/msg00616.txt.bz2 ------- Additional Comments From jistone at redhat dot com 2009-11-20 21:25 ------- (In reply to comment #1) > archiving irc yak on topic: > > fche anyway, I was thinking that another locking-related optimization could be > done by escalating read-to-write locks within probe handlers One concern is that we could lose atomicity this way. If two probes share a read lock, and one wants to upgrade to write, it could timeout in waiting for the other to release. Normally we can determine such skips on probe entry, so the handler is all or nothing. Or can we just allow the upgrade to block forever, since the shared probes are bounded by MAXACTION? -- http://sourceware.org/bugzilla/show_bug.cgi?id=10741 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.