From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25411 invoked by alias); 3 Mar 2005 09:32:52 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 25351 invoked from network); 3 Mar 2005 09:32:43 -0000 Received: from unknown (HELO wproxy.gmail.com) (64.233.184.207) by sourceware.org with SMTP; 3 Mar 2005 09:32:43 -0000 Received: by wproxy.gmail.com with SMTP id 71so393171wri for ; Thu, 03 Mar 2005 01:32:43 -0800 (PST) Received: by 10.54.73.11 with SMTP id v11mr74694wra; Thu, 03 Mar 2005 01:32:42 -0800 (PST) Received: by 10.54.7.8 with HTTP; Thu, 3 Mar 2005 01:32:42 -0800 (PST) Message-ID: <97ffb3105030301323c1bae1@mail.gmail.com> Date: Thu, 03 Mar 2005 09:32:00 -0000 From: Gottlob Frege Reply-To: Gottlob Frege To: pthreads-win32@sources.redhat.com Subject: starvation in pthread_once? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2005/txt/msg00016.txt.bz2 I'm concerned about the Sleep(0) in pthread_once: if (!once_control->done) { if (InterlockedIncrement (&(once_control->started)) == 0) { /* * First thread to increment the started variable */ (*init_routine) (); once_control->done = PTW32_TRUE; } else { /* * Block until other thread finishes executing the onceRoutine */ while (!(once_control->done)) { /* * The following gives up CPU cycles without pausing * unnecessarily */ Sleep (0); } } } IIRC, Sleep(0) does not relinquish time slices to lower priority threads. (Sleep(n) for n != 0 does, but 0 does not). So, if a lower priority thread is first in, followed closely by a higher priority one, the higher priority thread will spin on Sleep(0) *forever* because the lower, first thread will never get a chance to set done. So even Sleep(10) should be good enough. In theory, there could be enough higher priority threads in the system that the first thread still doesn't get in (ever?!), but unlikely. And that would probably mean a general design flaw of the calling code, not pthread_once. ?