From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6921 invoked by alias); 20 Nov 2009 21:28:34 -0000 Received: (qmail 6615 invoked by uid 48); 20 Nov 2009 21:28:23 -0000 Date: Fri, 20 Nov 2009 21:28:00 -0000 Message-ID: <20091120212823.6614.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/msg00617.txt.bz2 ------- Additional Comments From fche at redhat dot com 2009-11-20 21:28 ------- (In reply to comment #2) > One concern is that we could lose atomicity this way. Clearly we must not risk that. > If two probes share a > read lock, and one wants to upgrade to write, it could timeout in waiting for > the other to release. We could preclude this situation by applying this optimization only when we can prove that the code between the initial read-lock and the later read-write-lock is all side-effect-free. That way a timeout on the read-write lock would be equivalent to an ordinary skip. -- 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.