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] Problem with the queues
Date Fri, 21 Feb 2003 18:04:15 GMT
Jacob Lewallen wrote:

> Some more problems with apr_queue. . .
>
> Erwin De Wolff wrote:
>
>> My application uses queues and I notice that I had some difficulties 
>> when
>> reaching the end and start of the queue. I'm using the latest (21 
>> febr 2003)
>> snapshot of apr and apr-util. Platforms on which it occurs, Windows and
>> Linux. To make the problem more accessible I use most of the same 
>> code as
>> the testqueue.c provided in the distribution. Only to simplify I use one
>> producer and one consumer only and a queue of size 1. The producer 
>> pushes
>> values 0,1,2,3,... and the consumer pops them one by one. The following
>> output is obtained:
>>
>>     0: value 0 succesfully pushed.
>>     1: value 1 succesfully pushed.
>>             0: value 1 succesfully popped.
>>     2: value 2 succesfully pushed.
>>            1: value 2 succesfully popped.
>>     3: value 3 succesfully pushed.
>>            2: value 3 succesfully popped.
>>             3: value 3 succesfully popped.
>>
>> You can notice a few things:
>> 1. value 0 is never popped
>> 2. there are two values pushed on a queue of size 1!
>> 3. value 3 is popped twice on a queue of size 1.
>>
>> I don't think I made a mistake in the code, but just for those who might
>> doubt that, I attached the used code.
>>  
>>
> [code removed]
>
> Here's what's going on here. With a queue size of 1, there's only one 
> position in the queue for placing data. In apr_queue_pop, we return 
> the address of the popped item "in the queue's own array" (hence us 
> having to dereference twice to get our integer pointer above). So 
> here's how things breakdown:
>
> P: we push 0, its placed in data[0]
> P: we try to push 1, its blocked, because we're full
> C: we pop, and are returned the address of data[0] (in our case, a 
> pointer to where the pointer to 0 is zero)
> P: unblock, push 1 into the queue (overwriting data[0] with the new 
> pointer)
> C: we dereference the pointer to data[0] that was returned, which has 
> since been replaced with a pointer to 1.
>
> And this goes on. I think that this is responsible for all of the 
> behavior we see above. I'm almost positive that I've seen someone 
> complain about how the apr_queue code returns the address of the item, 
> rather than the value itself. This is what the attached patch does, if 
> anybody has any reason for keeping the existing behavior, I'd love to 
> hear them. This, of course, breaks any code that uses apr_queue_pop, 
> so it's a big deal.
>
> jacob lewallen
> jlewalle@cs.ucr.edu
>


Mime
View raw message