I have verified that the Windows behavior is different from UNIXes.  UNIXes do not lose signals when there are consumers waiting.  The signal is only lost when there are no consumers. 
However, the proposed fix is a heavy weight fix in that it creates a new event for every consumer and then destroys the event.  This has a lot of overhead.  Your suggestion of a counter is a better solution.  You can use the apr_atomic... functions on windows which uses the InterlockedExchange API and have much better performance.

----- Original Message ----
From: Salikh Zakirov <Salikh.Zakirov@Intel.com>
To: dev@apr.apache.org
Sent: Monday, January 15, 2007 2:25:29 PM
Subject: apr_thread_cond_signal() lost?


I have not get any response.
Assuming that silence was caused by the long vacation, resending in hope
to get some response.


Salikh Zakirov wrote:
> Hi,
> the current implementation of apr_thread_cond_signal() on Windows
> has a deficiency: it may lose several concurrent or sequential
> signal() calls if more than one thread is waiting on a condition
> variable, because there is no count of the number of signal() calls,
> and only one woken up thread will really come out of the loop.
> As far as I can see, APR condition variables are meant as a portable
> replacement for pthread condition variable, however, the lost signal()
> behaviour is not compliant with pthread_cond_signal() specification [1]:
>     The pthread_cond_signal() function shall unblock at least one of the
>     threads that are blocked on the specified condition variable cond
>     (if any threads are blocked on cond).
> Unfortunately, neither compliance nor defiance to this requirement is specified
> in APR manual, so I do not know if it is intentional or not.
> Can any of APR developers clarify their position?
> DRLVM [2] is using APR as its porting layer, however, due to the lost signal()
> issue it is forced to use its own implementation of conditional variables,
> currently arranged as an APR patch [3] (not really a patch, but a couple of
> files replaced).
> I am not the original author of the mentioned code, so I cannot submit it
> for inclusion into APR directly, however, the code is available from Apache
> Harmony repository licensed under AL2, and I know and can contact original
> author, though he has low motivation on submitting the patch himself.

I've submitted APR bug 41243 [41243] to track this issue.

> Can this fix be included into APR?
> [1] http://www.unix.org/single_unix_specification/, pthread_cond_signal() page
> [2] http://harmony.apache.org/subcomponents/drlvm/index.html
> [3]
> http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/build/patches/win/APR/locks/win32/thread_cond.c?view=markup
> http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/build/patches/win/APR/include/arch/win32/apr_arch_thread_cond.h?view=markup
> [41243] http://issues.apache.org/bugzilla/show_bug.cgi?id=41243

Salikh Zakirov

8:00? 8:25? 8:40? Find a flick in no time
with theYahoo! Search movie showtime shortcut.