From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pthreads-win32-return-852-listarch-pthreads-win32=sources.redhat.com@sources.redhat.com>
Received: (qmail 26689 invoked by alias); 8 Sep 2004 19:59:03 -0000
Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:pthreads-win32-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/pthreads-win32/>
List-Post: <mailto:pthreads-win32@sources.redhat.com>
List-Help: <mailto:pthreads-win32-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: pthreads-win32-owner@sources.redhat.com
Received: (qmail 26680 invoked from network); 8 Sep 2004 19:59:01 -0000
Received: from unknown (HELO mtagate2.de.ibm.com) (195.212.29.151)
  by sourceware.org with SMTP; 8 Sep 2004 19:59:01 -0000
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i88JwwFW154792;
	Wed, 8 Sep 2004 19:58:58 GMT
Received: from d12ml062.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i88JwvDu110284;
	Wed, 8 Sep 2004 21:58:58 +0200
In-Reply-To: <31173C0B4EF5D611A021009027CB2CBD04EE2CC6@fl08exm04>
MIME-Version: 1.0
Sensitivity: 
To: Blanco Alejandro-EAB005 <Alex.Blanco@motorola.com>
Cc: "'pthreads-win32@sources.redhat.com'" <pthreads-win32@sources.redhat.com>
Subject: Re: FW: sem_getvalue()
Message-ID: <OF8868FE33.7F2DC138-ONC1256F09.006B925D-C1256F09.006DC69C@de.ibm.com>
From: Alexander Terekhov <TEREKHOV@de.ibm.com>
Date: Wed, 08 Sep 2004 19:59:00 -0000
Content-Type: text/plain; charset="US-ASCII"
X-SW-Source: 2004/txt/msg00107.txt.bz2

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