From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 18 14:39:20 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 512C4106564A for ; Fri, 18 Feb 2011 14:39:20 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 0649B8FC0C for ; Fri, 18 Feb 2011 14:39:19 +0000 (UTC) Received: by qyk36 with SMTP id 36so386841qyk.13 for ; Fri, 18 Feb 2011 06:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=yC3gdUtSwTB/ic++eCC8EObNaE60ixH+NKk9f0wGZ7o=; b=lnCzAZYf8WKWP1uuOUz8cgQn0fxMKo4ogBWwQUG3rP3acQLfBieGlXKK/etA2suu7/ lJIgn7D83odSi/K5DeqY83HPoVc7DZbijURkwujU//TUkP5VsdVx0tZ8iuB9HEgKhy+R KwlR9ovrki3EBNy8uR/uT9vyKHuAJhT3j/SxA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sZ7JVBT65Tq66AnVDEoL5V0pTZQ7V04hxVoYVhd8uuVPJ6cNqrwh2BkRgEXe0Rv9q7 YYKOjKn4W6bWOGdwLm6A2qj7AUJANqZu2VIwn/zXWHt5HFFuMavJPcCu9FZcDVzWVVnh xhB8U6+LDI9oorjh9WyoufkD12/3EWxJtNIVU= MIME-Version: 1.0 Received: by 10.224.60.205 with SMTP id q13mr641377qah.60.1298038107027; Fri, 18 Feb 2011 06:08:27 -0800 (PST) Received: by 10.224.2.83 with HTTP; Fri, 18 Feb 2011 06:08:26 -0800 (PST) Date: Fri, 18 Feb 2011 15:08:26 +0100 Message-ID: From: Svatopluk Kraus To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Sleepable locks with priority propagation? 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: Fri, 18 Feb 2011 14:39:20 -0000 Hi, I deal with devices (i2c bus, flash memory), which are quite slow, i.e. some or mostly all operations on it are quite slow. One must wait for it for rather long time. Use of DELAY() is too expensive and an inactive (so called unbound) wait isn't permited with mutexes. So, no priority propagation locking primitive could be exploited. Typical simple operation (which must be locked) is following: HW_LOCK write request (fast) wait for processing (quite slow) read response (fast) HW_UNLOCK Here, use of mutex with mtx_sleep() is impossible, as mutex is unlocked during (unbound) sleep and somebody can start new operation. An response which is read after sleep could be incorrect. Well, I deal with a hardware, so all sleeps on it could be infinite. It's driver writer responsibility to ensure that all situations which can lead to infinite waits are treated correctly and can't happen. The waits (if no error happen on hardware, what must be treat anyway) could be rather long (but with known limits from specification). Long but not unbounded. I lack of a locking primitive with priority propagation on which inactive waits are permited. I'm not too much familiar with locking implementation strategy in FreeBSD, but am I one and only who needs such a lock? Or such lock is not permitted for really good reasons? Well, I know that only KASSERT in mtx_init() (mutex can't be made SLEEPABLE) and witness in mtx_sleep() (can't sleep on UNSLEEPABLE locks) quard the whole stuff. But should I hack it and use mutex as a locking primitive I need? (Of course, I will always use it with timeout.) Thanks for any response, Svata