Re: apr_thread_cond_signal() lost?

[E Holyat <eh...@yahoo.com>]

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 <Sa...@Intel.com>
To: dev@apr.apache.org
Sent: Monday, January 15, 2007 2:25:29 PM
Subject: apr_thread_cond_signal() lost?


Hi,

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

Thanks.

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


 
____________________________________________________________________________________
Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367

Re: fix for apr_thread_cond_signal() lost?

[PB <pb...@enseo.com>]

E Holyat <eholyat <at> yahoo.com> writes:

> 
> 
> 
> 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 <at>
Intel.com>To: dev <at> apr.apache.orgSent: Monday, January 15, 2007 2:25:29
PMSubject: apr_thread_cond_signal() lost?Hi,I have not get any response.Assuming
that silence was caused by the long vacation, resending in hopeto get some
response.Thanks.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.
> 






-----------------------------------------------------------------------


yes, the behavior of apr_thread_cond_signal is different on Windows and Unix.
Until the producer thread does the cond_signal, on Windows the consumer thread
sleeps ans awakens immediately. This means that the signal is not lost [is
high], even if the signalling is done before a consumer is waiting on it.
On Linux, however, the signal can be lost, because it doesn't persist.
A workaround to the following is this:

This will only work correctly on Linux.

producer thread code:

mutex_lock
flag = true;
apr_thread_cond_signal(..)
mutex_unlock

AND

consumer thread code:

mutex_lock
if(!flag)
{
   apr_thread_cond_wait OR timedwait
}
flag = false
mutex_unlock


For a cross platform implementation, simple solution would be to use #if WINDOWS
and to take off the part of the code above that uses "flag".

The other method would be to use two flag variables, flag and flag2 [initial
value false], as follows:This second flag is needed because on Windows, you need
to reset the cond_signal. which means on Windows, you either dont use any flags
at all, and make the code OS specific, or you do the following to make it work
on both linux and windows.

producer thread code:

mutex_lock
flag = true;

if (flag2)
{
    apr_thread_cond_signal(..)
}

flag2 = false;
mutex_unlock


AND

consumer thread code:

mutex_lock
if(!flag)
{
   flag2 = true
   apr_thread_cond_wait OR timedwait
}
flag = false
mutex_unlock


Hope this helps.

-PB

--------------------------------------------------------------------------