From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9564 invoked by alias); 8 Sep 2004 18:59:48 -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 9557 invoked from network); 8 Sep 2004 18:59:47 -0000 Received: from unknown (HELO motgate.mot.com) (129.188.136.100) by sourceware.org with SMTP; 8 Sep 2004 18:59:47 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i88Ixkih009457 for ; Wed, 8 Sep 2004 11:59:47 -0700 (MST) Received: from fl08exm02.comm.mot.com (fl08exm02.comm.mot.com [145.2.198.181]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i88IxUSh009434 for ; Wed, 8 Sep 2004 13:59:30 -0500 Received: by fl08exm02 with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Sep 2004 14:59:45 -0400 Message-ID: <31173C0B4EF5D611A021009027CB2CBD04EE2CC6@fl08exm04> From: Blanco Alejandro-EAB005 To: "'pthreads-win32@sources.redhat.com'" Subject: FW: sem_getvalue() Date: Wed, 08 Sep 2004 18:59:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2004/txt/msg00106.txt.bz2 I experienced an unusual return value from sem_getValue(), and traced it back to the actual POSIX spec that is troubling. I had thought this would return a value < 0 if there are threads waiting on the semaphore, where the absolute value is the number of threads waiting. I saw that it was returning 0 when I had a thread waiting. I looked up the spec (http://www.opengroup.org/onlinepubs/009695399/functions/sem_getvalue.html), and it says: > The sem_getvalue() function shall update the location referenced by the sval argument to have the value of the semaphore referenced by sem without affecting the state of the semaphore. The updated value represents an actual semaphore value that occurred at some unspecified time during the call, but it need not be the actual value of the semaphore when it is returned to the calling process. If sem is locked, then the object to which sval points shall either be set to zero **or** to a negative number whose absolute value represents the number of processes waiting for the semaphore at some unspecified time during the call. Is it really optional to return the negative number? Does the implementation, at least sometimes, return 0 only? Alex Blanco