httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@apache.org>
Subject Re: cvs commit: httpd-2.0/server/mpm/worker fdqueue.c
Date Thu, 09 Jan 2003 23:32:22 GMT
Brian Pane wrote:
> Greg Ames wrote:


>> apr_atomic_dec?  That does return something.

> The problem is that, since we have to use apr_atomic_cas for the
> increment (due to the lack of a return value on apr_atomic_inc),
> we can't use apr_atomic_dec on the same variable.  apr_atomic_cas
> works on apr_uint32_t, while apr_atomic_dec works on apr_atomic_t.
> If we could change the apr_atomic_inc/dec functions to use apr_uint32_t,
> this part of the fdqueue code could become a lot simpler.

I am certainly in favor of changing apr_atomic_inc/dec so they can be useful. 
I'm wondering if it's ok to use an ordinary apr type, like apr_uint32_t? or do 
we need special atomic types marked as volatile or memory-resident or whatever 
so that gcc won't assign them to registers or optimize them out or ???  I don't 
know the answer, but have seen kernel code do such things (OK Jeff, I've been 
infected by the GPL...no hope for me).

> I still have one more change I'm hoping to make in the fdqueue
> synchronization logic: move the queue manipulation code in
> ap_queue_push/pop outside the mutex protected region by maintaining
> a linked list of queue nodes with apr_atomic_casptr.  

Sounds good, as long as the pops are single threaded somehow, or if you have 
some other way of getting around the A-B-A cas pop window.

Greg


Mime
View raw message