11

In glibc, malloc is implemented with arenas. So, for example, it is possible that the memory first allocated by malloc and later freed in thread A can not be used by another call of malloc in thread B, since thread A and B may be in different arenas, and different arenas maintain different heaps and free lists of memory.

When it comes to C++ (maybe also C++11 since C++11 has a new standard), is the story still the same?

Or different threads actually share the same segment of heap and free list of memory, and new in one thread can allocate the memory first newed and later deleted by another thread?

If the answer is implementation dependent, then the question is how are they implemented in the major C++ compilers, such as g++, MVC++, icc?

EDIT

I think this question is valid in the sense that sometimes you launch many threads and in each thread you dynamically allocate/deallocate a big chunk of memory for a large number of objects, and you don't want the memory usage by your application to go ridiculously high.

curiousguy
  • 8,038
  • 2
  • 40
  • 58
Allanqunzi
  • 3,230
  • 1
  • 26
  • 58
  • 1
    C++ does not specify how the allocation functions are to be implemented, only what results they have to produce. – Kerrek SB Jul 04 '15 at 23:18
  • In practice `new` calls `malloc`. But it isn't clear what you are hoping to do with that information. – Marc Glisse Jul 04 '15 at 23:23
  • you mean `new` is implemented by `malloc`? Is this standardized? – Allanqunzi Jul 04 '15 at 23:25
  • 2
    Do **not** add the C-tag for C++ questions! – too honest for this site Jul 04 '15 at 23:27
  • Why this is downvoted? Is this not a valid question about C++ memory management? please explain!! – Allanqunzi Jul 04 '15 at 23:38
  • On linux at least, if you *"allocate/de[al]locate [a] big chunk [of] memory for a large number of objects"* and big is really big, it will use a dedicated memory map region that's returned to the OS afterwards. For small allocations: they'll be in the areas, but tend to average out. With virtual memory and swap it's very rarely a practical problem (especially for 64 bit apps). My advice: get on with your coding and worry about this if it ever manifests. – Tony Delroy Jul 04 '15 at 23:52
  • You should perhaps specify and,tag more exact environment, and/or declare you want to know if the language standard has any requirements about this. – hyde Jul 04 '15 at 23:55
  • I guess your question is: If you allocate 500MB of small objects in thread 1, then free them from thread 2, then allocate another 500MB in thread 1, will it reuse the memory you just freed? Is that right? – user253751 Jul 05 '15 at 03:23
  • @immibis, this is not my question, although I also would like to know the answer to your question. My question is (in terms of your words): If I allocate 500MB of small objects in thread 1, then free them later also in thread 1, then in thread 2 can I allocate the just freed 500MB in thread 1 for thread 2? In `glibc`, if thread 1 and 2 are in different arenas, then I can not do that for thread 2. I would like to know the answer in C++ or C++11. – Allanqunzi Jul 05 '15 at 04:06
  • The standard prior to C++11 does not know anything about threads, so it is allways implementation defined. –  Jul 05 '15 at 08:18

3 Answers3

2

This:

different threads actually share the same segment of heap and free list of memory, and new in one thread can allocate the memory first newed and later deleted by another thread

Purpose of the threads - share memory space. If you needn't this feature, you better use processes.

Tsyvarev
  • 60,011
  • 17
  • 110
  • 153
  • Please note that in C it's possible that free memory space accessible for some thread may be not accessible to another thread. I am asking the behavior in C++, I am not talking about something like accessing variables across different threads. – Allanqunzi Jul 04 '15 at 23:35
  • @Allanqunzi - if that is the case, don't bother with threads since their main advantage over processes is easier inter-thingy comms. – Martin James Jul 04 '15 at 23:47
  • @Allanqunzi "_it's possible that free memory space accessible for some thread may be not accessible to another thread_" Where? In which case? – curiousguy Nov 20 '19 at 01:32
1

C++ std and the allocator implementation you use are two different things.. If you use gcc to compile your C++ code, it by default uses glibc as the allocator. So if your gcc is a sufficiently newer version, it uses glibc with per-thread arenas and you are good to go.

John Paul
  • 81
  • 6
0

It depends. On windows, a thread that uses DLLs is not allowed to transfer memory ownership allocated in one DLL to another DLL. All news and deletes must must be performed on the "same side" of the DLL. While this is not strict a thread-issue, it does still imply that a thread can not simply transfer memory ownership to any other thread without knowing where the memory originated.

See Do (statically linked) DLLs use a different heap than the main program?

Community
  • 1
  • 1
Mark Lakata
  • 19,989
  • 5
  • 106
  • 123
  • 2
    There is no such thing as a "DLL based thread". Memory allocated in a DLL by "new" can't be deallocated in another DLL or the main application by "delete" - this is not related to threads. – user253751 Jul 05 '15 at 00:00
  • I changed the wording from "DLL based thread" to "thread that uses DLLs" as that is what I meant. – Mark Lakata Jul 05 '15 at 03:10
  • If the DLLs are compiled withthe same compiler and flags there is no problem with deallocating memory that was allocated in another DLL. –  Jul 05 '15 at 08:15