From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 4 18:19:26 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AA9A16A418 for ; Thu, 4 Oct 2007 18:19:26 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id E247713C46E for ; Thu, 4 Oct 2007 18:19:25 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so230876nfb for ; Thu, 04 Oct 2007 11:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=WJu+oFz5GcjlszjBnJdvIlk96OBYG0wB5i3VeVzh1O0=; b=D0Kj295xLQ37UncH82jYxRsj5YAIKcUSkDUcepKOImw3UdEN9yA9pWwtl+j3FzH8wBqsZcRnbEee5XwbN22PuslzDGwtXiMqWB6aJqblDvLgz1ZcCV5vTTVnktyDg+a1CbnEXTHlPMS6rlnI/jCNXEmGlZK0oFwaBj5FO+AC6AI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=oBL67iXkw939xxywCqe1yjcz0u7XprgVVAUsrBSbivBnlsZG82GP/3tKpwRg1zFp69ukSccMj2FMGYW2CeTBhIl3vuTE70lSSXhWh0PZcWZfX0cBbl2IvCLrE/rHTskMxTrzy85RBe8QFWvnJlke3+GNML3FoAG37zKubwl6LGw= Received: by 10.78.183.8 with SMTP id g8mr1349001huf.1191520469744; Thu, 04 Oct 2007 10:54:29 -0700 (PDT) Received: by 10.78.97.18 with HTTP; Thu, 4 Oct 2007 10:54:29 -0700 (PDT) Message-ID: <3bbf2fe10710041054x1c580bb2m892bf389a70c0e6c@mail.gmail.com> Date: Thu, 4 Oct 2007 19:54:29 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Alfred Perlstein" In-Reply-To: <20071003025418.GN31826@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071003015231.GJ31826@elvis.mu.org> <20071003025418.GN31826@elvis.mu.org> X-Google-Sender-Auth: 04137b305c274307 Cc: Daniel Eischen , hackers@freebsd.org Subject: Re: Critical Sections for userland. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2007 18:19:26 -0000 2007/10/3, Alfred Perlstein : > * Daniel Eischen [071002 19:46] wrote: > > On Tue, 2 Oct 2007, Alfred Perlstein wrote: > > > > >Hi guys, we need critical sections for userland here. > > > > > >This is basically to avoid a process being switched out while holding > > >a user level spinlock. > > > > Setting the scheduling class to real-time and using SCHED_FIFO > > and adjusting the thread priority around the lock doesn't work? > > Too heavy weight, we want to basically have this sort of code > in userland: > > /* assume single threaded process for now */ > static int is_critical; > > > > atomic_mutex_lock(); /* implies ++is_critical */ > ...do stuff... > atomic_mutex_unlock(); /* implies --is_critical */ > > We don't want two or more syscalls per lock operation. :) Basically, preemption in kernelspace is handled by using the td_critnest counter which should work in this way: - critical_enter() bumps td_critnest - if preemption is required or an ipi arrives and the operation is signalled with the td_owepreempt flag and will be deferred. - once critical_exit() is called the counter is decreased. If necessary (checking for td_critnest and td_owepreempt) the preemptive operation happens instantanely. It is all very fast and highly scalable as scope of operation is entirely per-thread so it doesn't require any lock. I think maybe you should use a very similar scheme to this. Attilio -- Peace can only be achieved by understanding - A. Einstein