Is heap management thread-local?

[John Doe]

Hi all,
I know the standard doesn't care about threads (wrongly

But in current compilers implementation, is the "list" which holds count
of the occupied and free heap addresses SHARED among various threads or not?

I don't know if I was clear:

Case1: the list which holds count of what is free and what is occupied
is SHARED among all the threads. In this case each
malloc/new/free/delete needs to acquire a mutex.

Case2: list (almost) thread local: no need for mutexes inside the
malloc/new/free/delete implementations, for most calls. So concurrent
access to malloc/new is fast

In this latter case of course there should be some heap address ranges
which are reserved for use by thread1, some are reserved for thread2...
so they don't usually conflict. If some thread fills up its address
range with mallocs, then it has to take a mutex and rearrange the
address ranges dedicated to the various threads so that it can get some
more heap range for the next mallocs...


I need to know the answer to evaluate if for fast
allocations/deallocations it should be wise to use something like an
allocator pool.




Oh another question: are distinct allocator functions for the various
classes automatically generated? It would seem wise to me to divide the
heap (or the section of the heap dedicated to one thread) in address
ranges, and each address range should be used for one class only. In
this way the allocation for various objects of the same type would be
contiguous and the memory would never be fragmented. Of course if one
class finishes its heap range, a reassignment of the heap ranges with
the other objects would have to be made.


TIA

 

[Rolf Magnus]

Hi all,
I know the standard doesn't care about threads

So you know you're off-topic here.

(wrongly

Depends on the view.

But in current compilers implementation, is the "list" which holds
count of the occupied and free heap addresses SHARED among various
threads or not?

Depends on the implementation, but I guess it is in most
implementations.

I don't know if I was clear:

Case1: the list which holds count of what is free and what is occupied
is SHARED among all the threads. In this case each
malloc/new/free/delete needs to acquire a mutex.

Or use one of the various other synchronization techniques, of which
some are in this case a lot better (more efficient) than mutexes.

Case2: list (almost) thread local: no need for mutexes inside the
malloc/new/free/delete implementations, for most calls. So concurrent
access to malloc/new is fast

In this latter case of course there should be some heap address ranges
which are reserved for use by thread1, some are reserved for
thread2... so they don't usually conflict. If some thread fills up its
address range with mallocs, then it has to take a mutex and rearrange
the address ranges dedicated to the various threads so that it can get
some more heap range for the next mallocs...

How could it rearrange the address space if there is already something
in it?

I need to know the answer to evaluate if for fast
allocations/deallocations it should be wise to use something like an
allocator pool.

There are quite a lot of malloc implemenations out there, and there may
be some that are quite efficient in multithreading environments. Just
google for them.

Oh another question: are distinct allocator functions for the various
classes automatically generated? It would seem wise to me to divide
the heap (or the section of the heap dedicated to one thread) in
address ranges, and each address range should be used for one class
only. In this way the allocation for various objects of the same type
would be contiguous and the memory would never be fragmented. Of
course if one class finishes its heap range, a reassignment of the
heap ranges with the other objects would have to be made.

Again, I wonder how you can reassign memory that is already in use.

 

[John Doe]

Hi all,

So you know you're off-topic here.

I thought I had posted to comp.lang.c++!
What's the difference with comp.std.c++ then??

How could it rearrange the address space if there is already something
in it?

You reassign the *free* space of course.
If all threads have used up all the address ranges that was assigned to
them, there is no way to malloc another thing!

Suppose you have 3 threads.
You divide all the heap space in 3 address ranges and assign each range
to a thread.

If thread1 uses all of it, and thread 2 and 3 still have mallocated
nothing, then at the next malloc on thread1 it will acquire the mutex
(or whatever it is), reassign globally free space equally among the
three threads (thread1 will own 1/3 + 2/9 of the heap space, not all
contiguous, the other two will own 2/9 each, contiguous), release the
mutex and then malloc.

Of course the delete/free function needs to be a little smarter: if the
thread who deletes is not the same as the thread who has mallocated, it
needs to acquire the mutex and go to the list of the other thread before
releasing the memory, but it would happen only in a minority of cases,
and never when doing malloc/new.

 

[Kevin Goodsell]

I thought I had posted to comp.lang.c++!
What's the difference with comp.std.c++ then??

comp.std.c++ discusses the C++ standard.

comp.lang.c++ discusses the C++ language as defined by the C++ standard.

This is off-topic here. Any meaningful discussion of this topic would
need a context (such as a particular threading implementation) that this
group does not provide.

-Kevin

 

[Steven T. Hatton]

So you know you're off-topic here.

The faq addresses threading issues. That seems to suggest to me they aren't
off topic here.

 

[Howard Hinnant]

The faq addresses threading issues. That seems to suggest to me they aren't
off topic here.

Additionally the word "thread" is contained in the C++ standard. So I
agree that this is on topic! ;-)

Typically heap memory is treated as global instead of thread local. The
motivation is to allow one thread to delete memory allocated by another
thread.

There is hope that a future C++ standard will address threading issues,
although nothing has been formally proposed yet. Unfettered discussion
of threading and how it relates to C++ could do nothing but help push
that process along.

-Howard

 

[Claudio Puviani]

Hi all,
I know the standard doesn't care about threads (wrongly

Why do newbies ALWAYS want to second-guess the battalion of experts who sit
on the standard committee? This is getting soooo old.

But in current compilers implementation, is the "list" which holds count
of the occupied and free heap addresses SHARED among various threads or not?

I don't know if I was clear:

Case1: the list which holds count of what is free and what is occupied
is SHARED among all the threads. In this case each
malloc/new/free/delete needs to acquire a mutex.

Case2: list (almost) thread local: no need for mutexes inside the
malloc/new/free/delete implementations, for most calls. So concurrent
access to malloc/new is fast

In this latter case of course there should be some heap address ranges
which are reserved for use by thread1, some are reserved for thread2...
so they don't usually conflict. If some thread fills up its address
range with mallocs, then it has to take a mutex and rearrange the
address ranges dedicated to the various threads so that it can get some
more heap range for the next mallocs...


I need to know the answer to evaluate if for fast
allocations/deallocations it should be wise to use something like an
allocator pool.




Oh another question: are distinct allocator functions for the various
classes automatically generated? It would seem wise to me to divide the
heap (or the section of the heap dedicated to one thread) in address
ranges, and each address range should be used for one class only. In
this way the allocation for various objects of the same type would be
contiguous and the memory would never be fragmented. Of course if one
class finishes its heap range, a reassignment of the heap ranges with
the other objects would have to be made.

See http://www.cs.umass.edu/~emery/hoard/ for answers to most of your
questions.

Claudio Puviani

 

[Mike Wahler]

Additionally the word "thread" is contained in the C++ standard. So I
agree that this is on topic! ;-)

The word 'thread' appears exactly once in the standard
(15.1/2). It's used in the context of exceptions.
Nothing to do with multithreading.

-Mike

 

[Howard Hinnant]

The word 'thread' appears exactly once in the standard
(15.1/2). It's used in the context of exceptions.
Nothing to do with multithreading.

You looked it up! Thanks, I knew somebody would. Perhaps my humor
is now more clear? <sigh> Perhaps not.

<speaking to this community, not just to Mike - who merely relayed a
fact:>

So, is it your opinion that threading as it relates to C++ is off topic
for comp.lang.c++?

Would it be on topic if a threading library had been accepted by the C++
standards committee into the TR1 Library report? What if it had been
proposed, but not accepted? What if people were just thinking about
proposing such a library? Or must topics (such as threading) be
officially voted in, and ratified by the ISO process before they can be
discussed on comp.lang.c++?

Before one answers, it is perhaps instructive to search
comp.lang.c++.moderated for discussions on this topic. Should the topic
policy on comp.lang.c++ be substantially different than the topic policy
on comp.lang.c++.moderated? If your answer is yes, perhaps you can be
partially credited with motivating the creation of
comp.lang.c++.moderated in the first place.

-Howard

 

[Steven T. Hatton]

You looked it up! Thanks, I knew somebody would. Perhaps my humor
is now more clear? <sigh> Perhaps not.

<speaking to this community, not just to Mike - who merely relayed a
fact:>

So, is it your opinion that threading as it relates to C++ is off topic
for comp.lang.c++?

Would it be on topic if a threading library had been accepted by the C++
standards committee into the TR1 Library report? What if it had been
proposed, but not accepted? What if people were just thinking about
proposing such a library? Or must topics (such as threading) be
officially voted in, and ratified by the ISO process before they can be
discussed on comp.lang.c++?

Before one answers, it is perhaps instructive to search
comp.lang.c++.moderated for discussions on this topic. Should the topic
policy on comp.lang.c++ be substantially different than the topic policy
on comp.lang.c++.moderated? If your answer is yes, perhaps you can be
partially credited with motivating the creation of
comp.lang.c++.moderated in the first place.

-Howard

1) Asking what is on topic is off topic. It's not covered in the Standard.
2) Telling people something is off topic is off topic. It's not covered in
the Standard.
3) Asking where to find the Standad is off topic. It's not covered in the
Standard.
4) You are not obligated to consider off topic discussion as relevent to
your choice as to what should be posted here.

Consult the FAQ, and follow your conscience. There /is/ a lot of stuff in
the FAQ, it's worth getting familiar with. If you're not.
http://www.parashift.com/c++-faq-lite/

BTW, what is a thread of control?

 

[Steven T. Hatton]

Hi all,
I know the standard doesn't care about threads (wrongly

But in current compilers implementation, is the "list" which holds count
of the occupied and free heap addresses SHARED among various threads or
not?

SHARED? You try'n t' say somep'n here?

 

[Graeme Prentice]

You looked it up! Thanks, I knew somebody would. Perhaps my humor
is now more clear? <sigh> Perhaps not.

<speaking to this community, not just to Mike - who merely relayed a
fact:>

So, is it your opinion that threading as it relates to C++ is off topic
for comp.lang.c++?

It's not my opinion. I'm astounded and disappointed that some people
might think so.

Would it be on topic if a threading library had been accepted by the C++
standards committee into the TR1 Library report? What if it had been
proposed, but not accepted? What if people were just thinking about
proposing such a library? Or must topics (such as threading) be
officially voted in, and ratified by the ISO process before they can be
discussed on comp.lang.c++?

I don't see why. C++ programmers need to know how to write
multithreaded programs using C++. It's far more on-topic here than in
comp.programming.threads. e.g. suppose you want to know if your library
is thread safe, or how to use it in a thread safe manner or how to use
heap memory in a thread safe manner in C++ or how to provide and use
synchronization functions in C++. Where could this possibly be more
on-topic than a C++ newsgroup? The "is my library thread safe" question
is often met with deafening silence. Maybe Metrowerks gives good
documentation on this, I don't know, but it's something many programmers
(including me) need C++ to provide better support for.

We're currently working on an embedded multithreaded C++ project using
GCC and when I came to investigate the threading issues, I was quite
surprised how little I knew about what volatile really does in C or C++
and whether or not it's useful for providing synchronization. With GCC,
we're using "asm volatile" with "memory" in the "clobber list" and
hoping that this prevents the compiler from performing optimisations and
caching across the asm. The GCC manual suggests this should work but
leaves some doubt in my mind. We're taking a guess that library
functions like printf are re-entrant! So I would really like the C++
language to provide better support and there's no place more on-topic
for discussing these issues than a C++ newsgroup in my opinion.

Graeme

 

[Alexander Terekhov]

:
[...]

BTW, what is a thread of control?

On POSIX systems, a thread is "a single flow of control within a
process***. Each thread has its own thread ID, scheduling priority
and policy, errno value, thread-specific key/value bindings, and
the required system resources to support a flow of control.
Anything whose address may be determined by a thread, including
but not limited to static variables, storage obtained via malloc(),
directly addressable storage obtained through implementation-
defined functions, and automatic variables, are accessible to all
threads in the same process."

regards,
alexander.

***) On mainframes...

General Programming Terms:

Application program
A collection of one or more programs cooperating to achieve
particular objectives, such as inventory control or payroll.

Environment
In Language Environment, normally a reference to the run-time
environment of HLLs at the enclave level.

Language Environment Terms and Their HLL Equivalents:

Routine
In Language Environment, refers to either a procedure,
function, or subroutine.

Equivalent HLL terms: COBOL--program; C/C++--function;
PL/I--procedure, BEGIN block.

Enclave
The enclave defines the scope of HLL semantics. In Language
Environment, a collection of routines, one of which is named
as the main routine. The enclave contains at least one thread.

Equivalent HLL terms: COBOL--run unit, C/C++--program,
PL/I--main procedure and its subroutines, and
Fortran--program and its subroutines.

Process
The highest level of the Language Environment program
management model. A process is a collection of resources,
both program code and data, and consists of at least one
enclave.

Thread
An execution construct that consists of synchronous
invocations and terminations of routines. The thread is
the basic run-time path within the Language Environment
program management model, and is dispatched by the system
with its own run-time stack, instruction counter, and
registers. Threads may exist concurrently with other
threads.

 

[E. Robert Tisdale]

comp.std.c++ discusses the C++ standard.

comp.lang.c++ discusses the C++ language as defined by the C++ standard.

This is off-topic here. Any meaningful discussion of this topic
would need a context (such as a particular threading implementation)
that this group does not provide.

That is, of course, your opinion. I don't entirely agree.
All things related to C++ are topical in the comp.lang.c++ newsgroup.
Certain issues, such as thread safety, are topical
but issues related to any particular thread library
should, in my opinion, be redirected to a more appropriate forum.