This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Memory allocators / STL


An additional question:
Has anyone an idea of why the application seems to run ok (not for a longer period of time, but anyway) when compiling __USE_MALLOC? Does this flag alter anything of the exception code inside STL or is the problem to some degree related to the memory allocation routines...

Any input is highlt appriciated...
...running out of ideas :(

Brgds

/Stefan

stefan@noname4us.com wrote:

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
>
>

-- 
Military intelligence is a contradiction in terms.
 
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]