Mailing-List: contact bugs-help@apr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apr.apache.org
From: bugzilla@apache.org
To: bugs@apr.apache.org
Subject: DO NOT REPLY [Bug 42305]  - rework win32 condition variable
In-Reply-To: <bug-42305-43213@http.issues.apache.org/bugzilla/>
Message-Id: <20070608174618.031A57141EE@brutus.apache.org>
Date: Fri,  8 Jun 2007 10:46:17 -0700 (PDT)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42305>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42305


------- Additional Comments From davi@haxent.com.br  2007-06-08 10:46 -------
I think that the semaphore wakeups are task priority and FIFO ordered. The
critical section contention is minimal because most of the time only one
thread is waked up. Even for broadcast case (wake up all threds) it won't
hurt much since the "critical" code is fairly fast (very few instructions).
Also, most high-performance mutex implementations spin (briefly) the lock
because going to kernel is way more costly, which is true for the broadcast case.

Besides this, there isnt much that can be done about fairness without kernel
help, that's probably why Vista ships a whole new CV primitive (WakeConditionVariable).
Linux fixed this issue by allowing waiters of condition variables (futex) to be
requeued to a mutex (FUTEX_CMP_REQUEUE).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org