From owner-freebsd-arch@FreeBSD.ORG Fri Jul 4 06:15:38 2014 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D3356E9 for ; Fri, 4 Jul 2014 06:15:38 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FB432300 for ; Fri, 4 Jul 2014 06:15:37 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 92B551FE02D for ; Fri, 4 Jul 2014 08:15:36 +0200 (CEST) Message-ID: <53B64694.9030100@selasky.org> Date: Fri, 04 Jul 2014 08:15:48 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: arch@FreeBSD.org Subject: Re: callout(9) really this complicated? References: <20140704041521.GW45513@funkthat.com> In-Reply-To: <20140704041521.GW45513@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 06:15:38 -0000 On 07/04/14 06:15, John-Mark Gurney wrote: > So, I was going to look at using callout(9) for some time delayed > actions... But upon reading the docs, a) the docs are inconsistent, > and b) the docs only talk about requirements in other section... > > Is there a better interface? If so, can we mark callout(9) deprecated? > If not, I have some questions... > > If you want callout_drain to work properly, you have to add extra code > to both your callout, and around the usage of it... > > callout_drain does not drain the callout: > However, the callout subsystem does guarantee that the callout will be > fully stopped before callout_drain() returns. > > Yet other parse of the docs say that you can depend upon the callout > being fully stopped.. I've sent email to Ian (iedowse) about why he > added this statement... > > Second, the amount of work you have to do to make sure you drain > seems pretty crazy as documented in Avoiding Race Conditions... > > It seems like if I have created a callout w/ callout_init_mtx, > that I shouldn't have to do extra work to make it work correctly... > > When calling _callout_stop_safe as callout_drain, there is no assert > that the lock is held, though it is documented as requiring it by: > The function callout_drain() is identical to callout_stop() except that > it will wait for the callout to be completed if it is already in > progress. > > Maybe we need to add an additional statement here? and assert that it > isn't locked? > > Also, I have tried to follow the code, but it's complicated, so I'm > hoping that I can get some help here. > > Thanks. > Hi, Probably the documentation needs an update. The implementation is fine. Basically like with many other multi processor APIs in the kernel: start and stop operations needs to be locked, not because of callout internals, but because of your driver staying sync. drain is always called unlocked. --HPS