Bitmap allocator documentation.
Dhruv Matani
dhruvbird@HotPOP.com
Fri Mar 12 10:02:00 GMT 2004
On Fri, 2004-03-12 at 08:59, Loren James Rittle wrote:
> In article <1078898573.11281.4.camel@localhost.localdomain>,
> Dhruv Matani<dhruvbird@HotPOP.com> writes:
>
> > Here is a revised version of the documentation based on various comments
> > I received. [...]
>
> Thank you Dhruv for the contribution and for updating to our local
> code conventions. I know you had a few agenda items which we deferred;
> we can incrementally patch over time to address them.
Yes, I can fix them as and when I get to know what I'm supposed to be
doing and am currently doing wrongly. Like the __GTHREADS that you have
mentioned below.
> One thing I did
> change in the documentation before commit: __GTHREADS is the static,
> primary way to adapt to threading configuration (use it to guard all
> __gthread* calls); consider using __gthread_active_p() to dynamically
> adapt run-time overhead (use it to guard actual mutex change calls).
> Also, we refrain from telling users to undefine library macros... ;-)
Ok.
But after reading it seems not so clear to me when I'm supposed to use
the macro and when the function, vaguely, it seems that I should be
using the macro to protect veriable declarations, and the function to
protect the actual locking of the mutex? However after looking at
mt_allocator.h, I could see something like:
#if defined __GTHREAD
if (__gthread_active_p())
//...
So is this protected by the macro or the function?
I could not find any documentation on gthreads, so if there is a place
please let me know.
However, peeking into the headers reveals that __gthread_active_p() just
compares the address of a function with zero. I guess this is done to
check the existence of the function in the code or something?
What does it do exactly?
> Patch installed on mainline with your updated documentation (I updated
> years and added boilerplate to the new tests). I reviewed it by hand,
> rebuilt/perf-checked. Attached is the final ChangeLog entry I used:
>
> 2004-03-11 Dhruv Matani <dhruvbird@HotPOP.com>
>
> * docs/html/ext/ballocator_doc.txt: New file.
> * include/Makefile.am (ext_headers): Add
> ${ext_srcdir}/bitmap_allocator.h .
> * include/Makefile.in: Regenerate (by hand, since I didn't have
> automake de jure on hand).
> * include/ext/bitmap_allocator.h: New file.
> * testsuite/performance/20_util/allocator/list_sort_search.cc: New test.
> * testsuite/performance/20_util/allocator/map_mt_find.cc: Likewise.
> * testsuite/performance/20_util/allocator/producer_consumer.cc: Add
> test for the bitmap_allocator<>.
> * testsuite/performance/20_util/allocator/insert.cc: Likewise.
> * testsuite/performance/20_util/allocator/insert_insert.cc: Likewise.
> * testsuite/performance/20_util/allocator/map_thread.cc: Likewise.
>
Thanks a lot!
There are a few things remaining as you have mentioned, and I'd like to
list them out. If you have anything else in mind or I may have missed
something out, please let me know.
1. Some variables still do not conform to the C++STYLE menioned in the
document.
2. Some functions are made public unnecessarily. I will make sure that
the scoping is correct.
3. The __GTHREADS issue that you have pointed out.
4. In the test-suite file, 4 macros are repeated (copy-paste error!).
I'll work on them and have a patch ready as soon as the gthreads issue
is sorted out.
--
-Dhruv Matani.
http://www.geocities.com/dhruvbird/
Proud to be a Vegetarian.
http://www.vegetarianstarterkit.com/
http://www.vegkids.com/vegkids/index.html
More information about the Libstdc++
mailing list