From owner-freebsd-threads@FreeBSD.ORG Sun Oct 11 00:03:59 2009 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B23410656A4; Sun, 11 Oct 2009 00:03:59 +0000 (UTC) (envelope-from sten@blinkenlights.nl) Received: from mx0.blinkenlights.nl (mx0.blinkenlights.nl [IPv6:2001:7b8:666:8000::25]) by mx1.freebsd.org (Postfix) with ESMTP id D95FC8FC2D; Sun, 11 Oct 2009 00:03:58 +0000 (UTC) Received: from bastard.snore.nl (bastard.snore.nl [IPv6:2001:7b8:666:ffff:0:42ff:fe00:4]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx0.blinkenlights.nl (Postfix) with ESMTPS id 81344CF390; Sun, 11 Oct 2009 02:03:58 +0200 (CEST) Received: by bastard.snore.nl (Postfix, from userid 1000) id 2A9A928A046; Sun, 11 Oct 2009 02:03:57 +0200 (CEST) X-Original-To: sten@blinkenlights.nl Delivered-To: sten@blinkenlights.nl Received: from mx0.blinkenlights.nl (mx0.blinkenlights.nl [IPv6:2a01:1b0:201:1::25]) by zaphod.blinkenlights.nl (Postfix) with ESMTP id 82E274AC053 for ; Thu, 15 May 2008 15:46:39 +0200 (CEST) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by mx0.blinkenlights.nl (Postfix) with ESMTP id 02DA47302B for ; Thu, 15 May 2008 15:46:38 +0200 (CEST) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 606AF177AE3; Thu, 15 May 2008 13:46:05 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 8BF0F10656B4; Thu, 15 May 2008 13:46:04 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E57C31065671; Thu, 15 May 2008 13:45:50 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 97A198FC13; Thu, 15 May 2008 13:45:50 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m4FDOu6r018326; Thu, 15 May 2008 09:24:56 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Thu, 15 May 2008 09:24:56 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andriy Gapon In-Reply-To: <482BF5EA.5010806@icyb.net.ua> Message-ID: References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> <482BF5EA.5010806@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: freebsd-stable@freebsd.org, David Xu , Brent Casavant , freebsd-threads@freebsd.org Subject: Re: thread scheduling at mutex unlock X-BeenThere: freebsd-threads@freebsd.org Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 11 Oct 2009 00:03:59 -0000 X-Original-Date: Thu, 15 May 2008 09:24:56 -0400 (EDT) X-List-Received-Date: Sun, 11 Oct 2009 00:03:59 -0000 On Thu, 15 May 2008, Andriy Gapon wrote: > Or even more realistic: there should be a feeder thread that puts things on > the queue, it would never be able to enqueue new items until the queue > becomes empty if worker thread's code looks like the following: > > while(1) > { > pthread_mutex_lock(&work_mutex); > while(queue.is_empty()) > pthread_cond_wait(...); > //dequeue item > ... > pthread_mutex_unlock(&work mutex); > //perform some short and non-blocking processing of the item > ... > } > > Because the worker thread (while the queue is not empty) would never enter > cond_wait and would always re-lock the mutex shortly after unlocking it. Well in theory, the kernel scheduler will let both threads run fairly with regards to their cpu usage, so this should even out the enqueueing and dequeueing threads. You could also optimize the above a little bit by dequeueing everything in the queue instead of one at a time. > So while improving performance on small scale this mutex re-acquire-ing > unfairness may be hurting interactivity and thread concurrency and thus > performance in general. E.g. in the above example queue would always be > effectively of depth 1. > Something about "lock starvation" comes to mind. > > So, yes, this is not about standards, this is about reasonable expectations > about thread concurrency behavior in a particular implementation (libthr). > I see now that performance advantage of libthr over libkse came with a price. > I think that something like queued locks is needed. They would clearly reduce > raw throughput performance, so maybe that should be a new (non-portable?) > mutex attribute. -- DE _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"