From owner-freebsd-hackers@freebsd.org  Sat Oct 13 15:40:08 2018
Return-Path: <owner-freebsd-hackers@freebsd.org>
Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68A0710CDF24
 for <freebsd-hackers@mailman.ysv.freebsd.org>;
 Sat, 13 Oct 2018 15:40:08 +0000 (UTC) (envelope-from lev@FreeBSD.org)
Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81])
 by mx1.freebsd.org (Postfix) with ESMTP id 0D4BA7F84D
 for <freebsd-hackers@FreeBSD.org>; Sat, 13 Oct 2018 15:40:07 +0000 (UTC)
 (envelope-from lev@FreeBSD.org)
Received: from lion.home.serebryakov.spb.ru (unknown
 [IPv6:2001:470:923f:1:5d37:62c7:7926:ca83])
 (Authenticated sender: lev@serebryakov.spb.ru)
 by onlyone.not-for.work (Postfix) with ESMTPSA id 5C3D7750
 for <freebsd-hackers@FreeBSD.org>; Sat, 13 Oct 2018 18:40:06 +0300 (MSK)
Date: Sat, 13 Oct 2018 18:40:06 +0300
From: Lev Serebryakov <lev@FreeBSD.org>
Reply-To: lev@FreeBSD.org
Organization: FreeBSD
Message-ID: <1551957390.20181013184006@serebryakov.spb.ru>
To: freebsd-hackers@FreeBSD.org
Subject: What are ck_queue.h guarantees?
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Oct 2018 15:40:08 -0000

Hello Freebsd-hackers,

  Concurrency Kit documentation says:

====
ck_queue is a queue.h-compatible implementation of many-reader-single-
writer queues. It allows for safe concurrent iteration, peeking and read-
side access in the presence of a single concurrent writer without any
usage of locks.
====

 But in all places at kernel I peeked, CK_XXXX macros are protected by
locks. Yes, even read ones.

  For example, there are a lot of addresses enumeration under locks in
 networks drivers, like this:

if_maddr_rlock(ifp);
CK_STAILQ_FOREACH(inm, &ifp->if_multiaddrs, ifma_link) {
    if (inm->ifma_addr->sa_family != AF_LINK)
        continue;
    crc = ether_crc32_le(LLADDR((struct sockaddr_dl *)
        inm->ifma_addr), ETHER_ADDR_LEN);

    /* Just want the 6 most significant bits. */
    crc >>= 26;

    /* Set the corresponding bit in the filter. */
    hash[crc >> 4] |= 1 << (crc & 0xf);
}
if_maddr_runlock(ifp);

  Why is it so? Why do we bother to use CK_XXX API (which adds all needed
barriers and uses CASes) if all accesses are protected by locks, anyway?

-- 
Best regards,
 Lev                          mailto:lev@FreeBSD.org