FW: sem_getvalue()

FW: sem_getvalue()

[Blanco Alejandro-EAB005]

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

Re: FW: sem_getvalue()

[Alexander Terekhov]

> if there are threads waiting on the semaphore

That's pretty useless info. Consider "fast" semaphore using "lock 
queue" (Linux folks reinvented "half-or-less" of this thing and 
proudly called it "a futex") address based parking interface with 
"waiters bit" maintained by its implementation:

sema_lock:

  WHILE // CAS/LL-SC
    !atomic_decrement_if_binand_7FFFFFFF_is_not_zero_ccacq(&lock) 
      lock_queue_wait(&lock, 0) // wait if sem.value is zero

sema_unlock:

  uintptr_t lock_queue;
  IF atomic_increment_rel(lock_queue = &lock) > 0x80000000
    THEN lock_queue_wake(lock_queue, 1)

(try/timed operations omitted for brevity)

BTW, fast mutex:

mutex_lock:

  WHILE 
    atomic_bit_test_set_ccacq(&lock, 1) 
      lock_queue_wait(&lock, 1) // wait if locked bit is set

mutex_unlock:

  uintptr_t lock_queue;
  IF atomic_decrement_rel(lock_queue = &lock)
    THEN lock_queue_wake(lock_queue, 1) 

"ccacq" stands for acquire-but-with-"control condition"-hint
(to avoid redundant memory barrier(s) -- arch specific stuff).

"rel" is a classic release.

regards,
alexander.

Re: FW: sem_getvalue()

[Ross Johnson]

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.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
>
>  
>

RE: FW: sem_getvalue()

[Alexander Terekhov]

http://www.opengroup.org/onlinepubs/009695399/basedefs/contents.html

I mean the definition of semaphore lock (and unlock) operation.

See also ("unofficial" aside for a moment):

http://www.pasc.org/interps/unofficial/db/p1003.1/pasc-1003.1-90.html

regards,
alexander.

RE: FW: sem_getvalue()

[Blanco Alejandro-EAB005]

What's xbd?  I was looking at an appendix for a POSIX spec and it defined it non-optionally.

-----Original Message-----
From: Alexander Terekhov [mailto:TEREKHOV@de.ibm.com] 
Sent: Thursday, September 09, 2004 9:55 AM
To: Blanco Alejandro-EAB005
Cc: 'Ross Johnson'; pthreads-win32@sources.redhat.com
Subject: RE: FW: sem_getvalue()


> "The updated value represents an actual semaphore value..."

Semaphore value is either zero or positive. See XBD. Reporting 
number of waiters as negative value is "optional" and you shall not rely on this feature. As I said, stay away from semas (if you have a choice).

regards,
alexander.

RE: FW: sem_getvalue()

[Alexander Terekhov]

> "The updated value represents an actual semaphore value..."

Semaphore value is either zero or positive. See XBD. Reporting 
number of waiters as negative value is "optional" and you shall
not rely on this feature. As I said, stay away from semas (if
you have a choice).

regards,
alexander.

RE: FW: sem_getvalue()

[Blanco Alejandro-EAB005]

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
>
>  
>

RE: FW: sem_getvalue()

[Alexander Terekhov]

Use condvars and mutexes. Avoid semaphores.

regards,
alexander.

RE: FW: sem_getvalue()

[Blanco Alejandro-EAB005]

the case is 1 thread sleeping, 2 threads may wake up the thread.  the wakers check to see if someone is waiting so the sem value is not positive after both wakers' conditions are met.  there is an obvious race condition, but for the application, this is ok.  

regardless, the question is whether there is a defect in that 0 is returned when it should be -1.

alex

-----Original Message-----
From: Alexander Terekhov [mailto:TEREKHOV@de.ibm.com] 
Sent: Wednesday, September 08, 2004 3:59 PM
To: Blanco Alejandro-EAB005
Cc: pthreads-win32@sources.redhat.com
Subject: Re: FW: sem_getvalue()


> if there are threads waiting on the semaphore

That's pretty useless info. Consider "fast" semaphore using "lock 
queue" (Linux folks reinvented "half-or-less" of this thing and 
proudly called it "a futex") address based parking interface with 
"waiters bit" maintained by its implementation:

sema_lock:

  WHILE // CAS/LL-SC
    !atomic_decrement_if_binand_7FFFFFFF_is_not_zero_ccacq(&lock) 
      lock_queue_wait(&lock, 0) // wait if sem.value is zero

sema_unlock:

  uintptr_t lock_queue;
  IF atomic_increment_rel(lock_queue = &lock) > 0x80000000
    THEN lock_queue_wake(lock_queue, 1)

(try/timed operations omitted for brevity)

BTW, fast mutex:

mutex_lock:

  WHILE 
    atomic_bit_test_set_ccacq(&lock, 1) 
      lock_queue_wait(&lock, 1) // wait if locked bit is set

mutex_unlock:

  uintptr_t lock_queue;
  IF atomic_decrement_rel(lock_queue = &lock)
    THEN lock_queue_wake(lock_queue, 1) 

"ccacq" stands for acquire-but-with-"control condition"-hint (to avoid redundant memory barrier(s) -- arch specific stuff).

"rel" is a classic release.

regards,
alexander.