This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Memory allocators / STL
- To: <gcc at gcc dot gnu dot org>, <libstdc++ at gcc dot gnu dot org>
- Subject: Re: Memory allocators / STL
- From: <stefan at noname4us dot com>
- Date: Fri, 26 Oct 2001 14:08:04 +0200
- Cc: Sinisa Milivojevic <sinisa at mysql dot com>
- References: <1004087190.3bd9279615fcb@webmail.noname4us.com> <15321.18211.713143.197981@sinisa.nasamreza.org>
Below is a very interesting comment from one of the MySQL developers (Thanks!)
and before we dwelve into redesign i would like to get some of the GCC people
to input on this topic.
Recap:
- Compiler GCC 3.0.1 with the bundled libstdc++
- Linux 2.4.12 (Slackware 8.0)
- Application is compiled with -static
- MySQL 3.23.43
Questions:
- Even if i redesign so that the application does not make use of any
exceptions, will the STL still do? Can this be disabled and what will the
effects be?
- Quite a few discussions on lists have been about __USE_MALLOC and other
compiletime flags/options. What are the "default" for a MT program - is there
really a need for anything else that -pthread at compile and -lpthread at link
time?
- Are there any of the STL containers that should be avoided in a MT enviorment
due to known bugs or have a large amount of overhead (i.e. thread locks)
Thanks in advance!
/Stefan
Quoting Sinisa Milivojevic <sinisa@mysql.com>:
> stefan@noname4us.com writes:
> > Hi!
> >
> > We are currently developing a MT server (pthreads based, the main
> thread
> > does accept() and push_back to a vector that the threads pick up work
> from,
> > the threads share a global hash_map of cached information protected by
> a
> > pthread_rwlock) and we seem to have an issue with confliting memory
> allocators
> > (locking).
> >
> > Our server is based purely on STL and we can get desent performance if
> we
> > compile it using the GCC/libstd++ flag __USE_MALLOC but this seems to
> lead
> > to high level of memory defragmentation since the server is bogged
> down
> > after a while of high load. From time to time we alse get memory leaks
> that
> > we can't pinpoint to anything else than fragmentation...
> >
> > Has anyone had this problem? I am sending this to the MySQL list since
> it
> > seems like the problem arises in combination with the mysql client
> library.
> > How does mysql allocate memory (treadsafety) and how could this
> collide with
> > the approach that the STL/GCC 3.0.1 does things?
> >
> > Thanks!
> >
> > /Stefan
>
> Hi!
>
> It is very well known that most C++ compilers have huge problems with
> threads when used in conjuction with C++ exceptions.
>
> GNU has this problem even agravated, as even if you do not use C++
> exceptions, libstdc++ does, so you will have problems.
>
> The only solution is not to use C++ exceptions and not to use
> libstdc++ with GNU C++.
>
> --
> Regards,
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic <sinisa@mysql.com>
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer
> /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
> <___/ www.mysql.com
>
>
> ---------------------------------------------------------------------
> Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail <mysql-thread89066@lists.mysql.com>
> To unsubscribe, e-mail
> <mysql-unsubscribe-stefan=noname4us.com@lists.mysql.com>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
>
>