From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10874 invoked by alias); 8 Sep 2004 20:17:12 -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 10867 invoked from network); 8 Sep 2004 20:17:11 -0000 Received: from unknown (HELO motgate7.mot.com) (129.188.136.7) by sourceware.org with SMTP; 8 Sep 2004 20:17:11 -0000 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i88KARIj028687 for ; Wed, 8 Sep 2004 13:10:28 -0700 (MST) Received: from fl08exm03.comm.mot.com (fl08exm03.comm.mot.com [145.2.198.183]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i88IGqGA010445 for ; Wed, 8 Sep 2004 13:16:53 -0500 Received: by fl08exm03 with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Sep 2004 16:17:05 -0400 Message-ID: <31173C0B4EF5D611A021009027CB2CBD04EE2CCC@fl08exm04> From: Blanco Alejandro-EAB005 To: "'Alexander Terekhov'" , Blanco Alejandro-EAB005 Cc: pthreads-win32@sources.redhat.com Subject: RE: FW: sem_getvalue() Date: Wed, 08 Sep 2004 20:17:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2004/txt/msg00108.txt.bz2 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.