From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24041 invoked by alias); 20 Nov 2009 19:43:46 -0000 Received: (qmail 24012 invoked by uid 48); 20 Nov 2009 19:43:33 -0000 Date: Fri, 20 Nov 2009 19:43:00 -0000 Message-ID: <20091120194333.24011.qmail@sourceware.org> From: "fche 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/msg00613.txt.bz2 ------- Additional Comments From fche at redhat dot com 2009-11-20 19:43 ------- 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, suchly: fche global foo probe bar { if (foo) { foo++ } } fche so the idea would be to initially read-lock foo, and only later upgrade it to a write-lock fche the theory being that some / many (??) probes start with some condition checking, and some (???) of that time, a write does not actually end up happening jistone hmm jistone have to think about whether that could induce any lock inversion fche oh yeah, lots of complications fche just wanted to brain-dump here FWIW jistone probe foo { if (++a) ++b } probe bar { if (++b) ++a } global a,b jistone does the initial read lock solve that? I think it might... -- 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.