apr_thread_cond_signal() lost?

[Salikh Zakirov <Sa...@Intel.com>]

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.

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

Re: apr_thread_cond_signal() lost?

[Salikh Zakirov <Sa...@Intel.com>]

Salikh Zakirov wrote:
> 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.
> ...

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