apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: apr_atomic stuff... planning to move all implementation out of the header file
Date Mon, 17 Nov 2003 16:48:28 GMT
Brian Pane wrote:

> +0.99
> While there are technically good reasons to require that all of
> these functions be inlined (like the increased probability that
> an atomic_cas based spinlock will fail and have to retry if there's
> a function call in the critical path)

good point...  OTOH, that slightly-increased contention rate will help expose 
faulty c-a-s logic sooner ;)

Too bad I didn't think about this in a previous life, but I suspect that 
applying a temporary hack to the apr compare-and-swap function to do a 
pthread_yield or equivalent would be good for testing too.  I recall too well a 
bug in some supervisor state code that appeared to work great on my 2nd-level 
(virtual) MVS but would (spin-) lock up pretty soon after applying load when 
running on a real SMP box.

View raw message