From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32322 invoked by alias); 5 Jan 2006 06:08:46 -0000 Received: (qmail 32304 invoked by uid 48); 5 Jan 2006 06:08:44 -0000 Date: Thu, 05 Jan 2006 06:08:00 -0000 Message-ID: <20060105060844.32303.qmail@sourceware.org> From: "hunt at redhat dot com" To: systemtap@sources.redhat.com In-Reply-To: <20051214214948.2056.hunt@redhat.com> References: <20051214214948.2056.hunt@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug translator/2056] avoid locking within foreach iteration for maps & pmaps X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q1/txt/msg00007.txt.bz2 ------- Additional Comments From hunt at redhat dot com 2006-01-05 06:08 ------- (In reply to comment #3) > Regarding the pmap deadlock, one possible fix is to have foreach() iterating > over a pmap hold an exclusive lock around the whole loop, and the @extraction > operators to hold none, when they're nested within foreach(). In fact, ordinary > array reads enclosed within foreach() don't need to be locked either. Let's > transmute this bugzilla entry to track this bug. Maybe I'm missing something, but the problem is the writelock. Why does the generated code take a writelock on the pmap when it is reading stats? I suspect the reason is confusion over reading from a map and a pmap. You need a writelock when doing _stp_pmap_agg() or _stp_pmap_get(). However, _stp_pmap_agg() creates a normal map and you only want to readlock it when reading. Until this gets fixed, pmaps of stats are broken because we cannot print without using foreach. -- http://sourceware.org/bugzilla/show_bug.cgi?id=2056 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.