From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32113 invoked by alias); 9 Sep 2004 12:59:16 -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 32089 invoked from network); 9 Sep 2004 12:59:13 -0000 Received: from unknown (HELO motgate3.mot.com) (144.189.100.103) by sourceware.org with SMTP; 9 Sep 2004 12:59:13 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i89CxCtd028565 for ; Thu, 9 Sep 2004 05:59:12 -0700 (MST) Received: from plnt059.comm.mot.com (plnt059.comm.mot.com [154.70.4.38]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i89CpERv016286 for ; Thu, 9 Sep 2004 07:51:15 -0500 Received: by plnt059.comm.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 9 Sep 2004 08:59:10 -0400 Message-ID: <31173C0B4EF5D611A021009027CB2CBD04EE2CCE@fl08exm04> From: Blanco Alejandro-EAB005 To: "'Ross Johnson'" Cc: pthreads-win32@sources.redhat.com Subject: RE: FW: sem_getvalue() Date: Thu, 09 Sep 2004 12:59:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2004/txt/msg00111.txt.bz2 I got an answer on a different email thread from one of the people who worked on the spec. The answer I got was that the "or" in the statement was just to deal with the temporal concerns - i.e. that at some time during the call, the number of threads waiting may be changing, so 0 or a negative number are valid, but that the important part of the statement is: "The updated value represents an actual semaphore value..." and that the intent was definitely that the number be negative when it is known threads are waiting. I'm not familiar enough with the code to offer a patch, but is it an easy update to support this? I looked at where the value is determined, but I could not really figure out whether it was possible. Alex -----Original Message----- From: pthreads-win32-owner@sources.redhat.com [mailto:pthreads-win32-owner@sources.redhat.com] On Behalf Of Ross Johnson Sent: Thursday, September 09, 2004 5:11 AM To: pthreads-win32@sources.redhat.com Subject: Re: FW: sem_getvalue() The pthreads-win32 implementation never returns a negative number, only zero or a positive number (i.e. the actual semaphore value as close as can be determined). I read it as optional because it could easily be written unambiguously. However, it would be worth asking the austin group list for a clarification. Ross Blanco Alejandro-EAB005 wrote: >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.h >tml), 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 > > >