From owner-freebsd-arch@FreeBSD.ORG Wed Mar 11 12:16:51 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E389355 for ; Wed, 11 Mar 2015 12:16:51 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2954184 for ; Wed, 11 Mar 2015 12:16:50 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 96E891FE022; Wed, 11 Mar 2015 13:16:41 +0100 (CET) Message-ID: <55003258.7010601@selasky.org> Date: Wed, 11 Mar 2015 13:17:28 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "freebsd-arch@freebsd.org" , Marshall Kirk McKusick Subject: Giving names to "new" locking techniques Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 12:16:51 -0000 Hi, What I'm writing here might become topic for a presentation educating other kernel developers at the next EuroBSDcon, so be warned ;-) Some of you familiar to farming knows what happens when you try to kill a chicken using a simple axe. It runs around for a long time after the head is off. This picture can also be used to explain what happens when trying to stop a process in the kernel which is using many different APIs. I think it would be benificial to all developers if new code techniques and solutions to classic locking problems could have a name, that can later be referred and explained, so that we don't go around and stumble and re-invent the wheel when writing [new] code. I attended a talk by Kirk McMusic some years ago where he explained how turnstiles and the internals of the locking system in FreeBSD worked. And I couldn't agree more. Many other people listening did not fully understand what he said. I think there is a strong need to educate people on how to properly use locks and mutexes inside the FreeBSD kernel and not only how locks work internally. I've recently been doing some work in the callout area and I would recommend other developers reading the "AVOIDING RACE CONDITIONS" section in "man 9 timeout" and making up your mind about the three no-name techniques described there. I think it would be fair to force everyone to avoid races using a any kind of exclusivly locked mutex, which is described as "alternative 1" in "man 9 callout". Further I would like the "AVOIDING RACE CONDITIONS" techniques in the callout subsystem to be the good example for everyone else. The USB stack already does similarly to the callout subsystem and it works excellent. And I would like the tools to be available in the kernel to do this easily, like an any-lock API similar to the existing locking classes in 11-current. While at it I would like to collect some terms and words related to locking: - Sleep/non sleepable lock (credits: ???) - Shared/exclusive lock (credits: ???) - Locking order reversal, LOR (credits: ???) - Lock inversion (credits: des@ ???) - Locking whole pieces of code and not only single variables or structures (credits: hselasky@ ???) - Applying locks before calling a function and not inside a function (credits: hselasky@ ???) - Any-locking API. A set of kernel functions that accepts any type of mutex: mtx / SPIN / RM / RW / SX which can be used by API providers to call callback functions locked (credits: ???) Thanks for reading through! Any comments? --HPS