From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 7 08:45:00 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D4C416A420 for ; Tue, 7 Mar 2006 08:45:00 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8269F43D46 for ; Tue, 7 Mar 2006 08:44:59 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by zproxy.gmail.com with SMTP id k1so1458275nzf for ; Tue, 07 Mar 2006 00:44:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tGvLs80TbJQaDwbg3aXGoIrcfL2nxHSYTPo6xcPLv6VyVyVGrSR1Ky6lrNfOkEIVE6LhL9NzRUPs5m8wOJ7JS5rYO3y9huy7FVjdg9ETFJzSdhvRYMgvQYGpCaH4FldbepcXdN29NTw5hXC8e9DOozGyENeeiudtE8Iyhuvo4LM= Received: by 10.36.196.1 with SMTP id t1mr226984nzf; Tue, 07 Mar 2006 00:44:58 -0800 (PST) Received: by 10.36.41.11 with HTTP; Tue, 7 Mar 2006 00:44:58 -0800 (PST) Message-ID: <3bbf2fe10603070044j745d5509n@mail.gmail.com> Date: Tue, 7 Mar 2006 09:44:58 +0100 From: "Attilio Rao" To: dima <_pppp@mail.ru> In-Reply-To: MIME-Version: 1.0 References: <200603061353.13756.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Re[2]: wakeup idea... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rookie@gufi.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2006 08:45:00 -0000 2006/3/6, dima <_pppp@mail.ru>: > Sorry my ignorance. Gleb Smirnoff pointed that out privately already. I looked at the code > and it seems very much like OpenSolaris implementation to me. You can't propagate > priority properly if you don't hold all the current lock holders somewhere. I tried to > implement it as an array in my effort. As Attilio Rao mentioned, this allows only fixed > amount of concurrent readers at the time (which is not quite right, but can be implemented > as a per-lock sysctl tuneable). I chose an array to prevent introducing one more mutex to > the SX lock on the "short path". The code might look as the following: You can't use a tunable sysctl if you plan to use a static array beacause you work a compile-time and a malloc'ing stub is too much inefficient. There's another problem too: dimensions. If you choice too much owners you will have something like (sorry, I've no= t seen the code yet): static struct thread *owners[NOWNERS]; On x86 sizeof(struct thread *) =3D=3D 4 so owners table dimension is NOWNER= S * 4 which is not so good. Tracking owners is the biggest problem of this issue. > This code is buggy, though. The array consisted of u_int32_t values first= , but it is hard to > handle the recursive case this way. Introducing a structure makes it impossible to handle > the array atomically. I'm still stuck at this point and some other issues (removing the locks > on thread_exit is the largest one among them). Handle recursion is simple if you get owners list per-turnstile or per-your-primitive. The main problem at this point is tracking owner. If you do in a static way (as you do now) you are limited by number of item= s and dimensions if you do in a dynamic way (using a TAILQ) you are limited in performance. Greetings, Attilio -- Peace can only be achieved by understanding - A. Einstein