From owner-freebsd-threads@FreeBSD.ORG Thu May 15 22:37:43 2008 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 2C07A1065671; Thu, 15 May 2008 22:37:43 +0000 (UTC) (envelope-from davids@webmaster.com) Received: from mail1.webmaster.com (mail1.webmaster.com [216.152.64.169]) by mx1.freebsd.org (Postfix) with ESMTP id 128EF8FC1C; Thu, 15 May 2008 22:37:42 +0000 (UTC) (envelope-from davids@webmaster.com) Received: from however by webmaster.com (MDaemon.PRO.v8.1.3.R) with ESMTP id md50002053693.msg; Thu, 15 May 2008 15:38:23 -0700 From: "David Schwartz" To: Date: Thu, 15 May 2008 15:37:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <482CA372.3000400@icyb.net.ua> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Authenticated-Sender: joelkatz@webmaster.com X-Spam-Processed: mail1.webmaster.com, Thu, 15 May 2008 15:38:23 -0700 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 206.171.168.138 X-Return-Path: davids@webmaster.com X-MDAV-Processed: mail1.webmaster.com, Thu, 15 May 2008 15:38:24 -0700 Cc: freebsd-stable@freebsd.org, freebsd-threads@freebsd.org Subject: RE: thread scheduling at mutex unlock X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davids@webmaster.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2008 22:37:43 -0000 > David, =20 > thank you for the tutorial, it is quite enlightening. > But first of all, did you take a look at my small test program? Yes. It demonstrates the classic example of mutex abuse. A mutex is not = an appropriate synchronization mechanism when it's going to be held most = of the time and released briefly. > There are 1 second sleeps in it, this is not about timeslices and=20 > scheduling at that level at all. This is about basic expectation about = > fairness of acquiring a lock at macro level. I know that when one = thread=20 > acquires and releases and reacquires a mutex during 10 seconds while = the=20 > other thread is blocked on that mutex for 10 seconds, then this is not = > about timeslices. I guess it comes down to what your test program is supposed to test. = Threading primitives can always be made to look bad in toy test programs = that don't even remotely reflect real-world use cases. No sane person = optimizes for such toys. The reason your program behaves the way it does is because the thread = that holds the mutex relinquishes the CPU while it holds it. As such, it = appears to be very nice and is its dynamic priority level rises. In a = real-world case, the threads waiting for the mutex will have their = priorities rise while the thread holding the mutex will use up its = timeslice working. This is simply not appropriate use of a mutex. It would be absolute = foolishness to encumber the platform's default mutex implementation with = any attempt to make such abuses do more what you happen to expect them = to do. In fact, the behavior I expect is the behavior seen. So the defect is in = your unreasonable expectations. The scheduler's goal is to allow the = running thread to make forward progress, and it does this perfectly. DS