pthread_join and thread stack

[Kevin Regan]

Just curious -- why is the memory for the thread held until
pthread_join is called? It seems like a significant waste of
resources. Also, it seems that you would want the freeing to happen
asynchronously (while the system may have idle cycles) rather than
forcing the additional computation during a synchronous call to
pthread_join in the "main" thread.

Are there specific implementation issues that make it hard to free the
thread stack during a pthread_exit()?

--Kevin

[loic...@gmx.net]

Hello Kevin,

> Just curious -- why is the memory for the thread held until
> pthread_join is called? It seems like a significant waste of
> resources. Also, it seems that you would want the freeing to happen
> asynchronously (while the system may have idle cycles) rather than
> forcing the additional computation during a synchronous call to
> pthread_join in the "main" thread.

This is implementation dependent, I guess. Strictly speaking, the only
information that must be kept when a joinable thread terminates is the
thread id and the pointer returned by the thread.

Of course, if you don't need thread's return value, you might detach
the thread (or create it detached from the start).

> Are there specific implementation issues that make it hard to free the
> thread stack during a pthread_exit()?

IIRC, LinuxThreads was such an example. However, I don't remember
exactly if this was due an "un-optimized coding", or a technical
limitation the way the thread's stack was set-up.

Cheers,
Loic.

[Paul Pluzhnikov]

loic...@gmx.net writes:

>> Are there specific implementation issues that make it hard to free the
>> thread stack during a pthread_exit()?
>
> IIRC, LinuxThreads was such an example.

NPTL is another. And AIX threads another.

What often happens is that the "thread descriptor" resides in the
same block of memory that is used for the thread stack (i.e. a single
mmap() of say 8MB is performed, thread descriptor is set up at the
end of that memory area, and the rest is used as the thread stack).

This setup makes it difficult to "free" the stack without also
"free"ing the thread descriptor.

IIRC, Solaris threads do this as well.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[David Schwartz]

Kevin Regan wrote:
> Just curious -- why is the memory for the thread held until
> pthread_join is called? It seems like a significant waste of
> resources.

Otherwise, the thread ID could be reused. In that case, how would you
know which thread you were joining?

> Also, it seems that you would want the freeing to happen
> asynchronously (while the system may have idle cycles) rather than
> forcing the additional computation during a synchronous call to
> pthread_join in the "main" thread.

That's why we have detached threads.

> Are there specific implementation issues that make it hard to free the
> thread stack during a pthread_exit()?

Some implementations free the thread stack as soon as the thread
terminates.

DS

[roger.f...@sun.com]

Paul Pluzhnikov wrote:
> loic...@gmx.net writes:
>
> >> Are there specific implementation issues that make it hard to free the
> >> thread stack during a pthread_exit()?
> >
> > IIRC, LinuxThreads was such an example.
>
> NPTL is another. And AIX threads another.
>
> What often happens is that the "thread descriptor" resides in the
> same block of memory that is used for the thread stack (i.e. a single
> mmap() of say 8MB is performed, thread descriptor is set up at the
> end of that memory area, and the rest is used as the thread stack).
>
> This setup makes it difficult to "free" the stack without also
> "free"ing the thread descriptor.
>
> IIRC, Solaris threads do this as well.

No. At least in Solaris 9 and 10, thread stacks that are allocated by
the
library (using mmap()) are freed for reuse immediately upon thread
termination. The thread structure, containing the thread-id and the
return value, is not freed until pthread_join() (or pthread_detach()).

A cache of up to 10 thread stacks is kept for rapid reuse for new
threads. Older stacks beyond the cache limit are munmap()d.

Roger Faulkner
Sun Microsystems

[Steve Watt]

In article <1163526374.7...@h54g2000cwb.googlegroups.com>,

Depends on the implementation. If you have an implementation of
pthread_exit() that does most of its work in userland, running on
that stack, it's rather hard to free it.

However, I suspect that holding the stack until pthread_join
is mostly a leftover concept from pure-userland thread
implementations. Fortunately those are mostly going away.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3"
Internet: steve @ Watt.COM Whois: SW32-ARIN
Free time? There's no such thing. It just comes in varying prices...

[juday...@gmail.com]

Some of the design considerations causes the thread structure
to be present:
- HP-UX seperates the stack and thread structure, so that we
can use the stack while the thread is not joined yet.
- Even thread structures could be cached and makes it convinent to have
all the
thread information in one structure. Information like not only tid,
return
value, will have attribute information and implementation specific
information
and may want to keep the structure intact.
- Another design challange would be to free the thread structure for
which you need
to have the lock.

Regards,
Uday Kiran Jonnala