This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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


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


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