NetBSD Problem Report #38554

From martin@duskware.de  Thu May  1 11:45:15 2008
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 0CD0063B8A5
	for <gnats-bugs@gnats.netbsd.org>; Thu,  1 May 2008 11:45:15 +0000 (UTC)
Message-Id: <20080501003928.B36D763B8A5@narn.NetBSD.org>
Date: Thu,  1 May 2008 00:39:28 +0000 (UTC)
From: ad@netbsd.org
Reply-To: ad@netbsd.org
To: netbsd-bugs-owner@NetBSD.org
Subject: kernel condvar wait functions should take an absolute timeout
X-Send-Pr-Version: www-1.0

>Number:         38554
>Notify-List:    paul@whooppee.com
>Category:       kern
>Synopsis:       kernel condvar wait functions should take an absolute timeout
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu May 01 11:50:00 +0000 2008
>Last-Modified:  Mon Jun 27 11:00:04 +0000 2016
>Originator:     Andrew Doran
>Release:        4.99.62
>Organization:
The NetBSD Project
>Environment:
n/a
>Description:
When sleeping on condition variables in the kernel, threads must be
prepared to handle "spurious wakeups": wakeups that occur due to some
external agent and do not signal an event of interest to the sleeping 
thread.

We have lots of code segments that do, for example:

  while (!condition) {
     error = cv_timedwait(&cv, &lock, hz);
     if (error == EWOULDBLOCK)
       break;
     ...
  }

If a spurious wakeup occurs, the thread could sleep for N*hz instead
of hz, or it could awaken early and return. Early wakeups are bad news 
for syscalls like nanosleep().
>How-To-Repeat:
Code inspection.

>Fix:
Make condvars take an absolute timeout and add some simple functions
to help with computing wakeup times. The above code fragment would
then look something like the following:

  when = cv_time_now() + cv_time_second();
  while (!condition) {
     error = cv_timedwait(&cv, &lock, when);
     if (error == EWOULDBLOCK)
       break;
     ...
  }

This makes condvars slightly more compatible with the Solaris
interfaces. I think it should also be done before 5.0, because
it's a fairly major change to the interface and it would be good
to have it full stable before it is set in stone.

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->ad
Responsible-Changed-By: ad@NetBSD.org
Responsible-Changed-When: Thu, 01 May 2008 12:22:01 +0000
Responsible-Changed-Why:
take


From: Jason Thorpe <thorpej@shagadelic.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: kern/38554: kernel condvar wait functions should take an absolute timeout
Date: Thu, 1 May 2008 21:38:46 -0700

 On May 1, 2008, at 4:50 AM, ad@netbsd.org wrote:

 > This makes condvars slightly more compatible with the Solaris
 > interfaces. I think it should also be done before 5.0, because
 > it's a fairly major change to the interface and it would be good
 > to have it full stable before it is set in stone.


 Agreed.  What sort of timeout value do the Solaris CV routines take?   
 Timespec?

 -- thorpej

From: yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
To: gnats-bugs@NetBSD.org
Cc: ad@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
        ad@netbsd.org
Subject: Re: kern/38554: kernel condvar wait functions should take an absolute
 timeout
Date: Fri,  2 May 2008 14:12:57 +0900 (JST)

 > What sort of timeout value do the Solaris CV routines take?   
 > Timespec?

 clock_t.

 YAMAMOTO Takashi

Responsible-Changed-From-To: ad->kern-bug-people
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Mon, 09 Apr 2012 05:58:17 +0000
Responsible-Changed-Why:
ad resigned, should not own PRs any more


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.