apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Lewallen <jlewa...@cs.ucr.edu>
Subject Re: [PATCH] apr_queue race condition
Date Mon, 10 Feb 2003 20:17:17 GMT
Ian Holsman wrote:

>On Sun, 09 Feb 2003 13:28:13 -0800, Jacob Lewallen wrote:
>>   Hi there, I've stumbled on a bug in the apr_queue_t code... When
>>calling apr_queue_pop to retrieve an item from the queue the call may
>>block indefinately despite items having been pushed in. Same things goes
>>for calls to apr_queue_push that are blocking until there is room in the
>>queue (they may stay blocked even though items have been popped from the
>>queue). The problem lies in the logic that manages the two conditions that
>>help operate the queue - NOT_EMPTY, and NOT_FULL. In apr_queue_push, the
>>NOT_EMPTY condition is only signaled if the queue was empty prior to
>>adding the new item. This can cause problems if there are multiple threads
>>blocked in calls to apr_queue_pop and then two or more successive calls to
>>apr_queue_push are handled prior to one of the apr_queue_pop awakening...
>>for example:
>another approach would be just to send signals every time a pop/push
>occurs, or to have the pop/push wake every waiting thread and try to get
>them to re-lock it.
   Yes, this would absolutely work and was something I did in narrowing 
down the problem. My intention in the patch was to keep the spirit of 
the original implementation and only signal when necessary, since that 
seemed to be a good idea. The solution is really unimportant to me, but 
I make heavy use of apr_queue in some software of mine so a working 
apr_queue is my priority. Thanks,

jacob lewallen

View raw message