thread stack size
Ying
Hello there,
I'm working on a project on Solaris SPARC 2.5 with Solaris multi-thread
library. Could anybody shed some light on how to get a thread's memory usage
and stack size, either Solaris thread library or Posix thread library?
thr_stksegment() gives the stack size allocated to a thread, which is 1M by
default. But what I want is the actual stack size or memory a thread
currently uses when the program is running.
Another question is about alarm and sleep. Posix thread does not support
per-thread alarm, does it support per-thread sleep() function? How about
solaris 2.5 thread?
Thanks in advance.
Ying
Steve Watt
In article <6idpit$qs6$1...@inet16.us.oracle.com>,
Ying <yz...@us.oracle.com> wrote:
> Could anybody shed some light on how to get a thread's memory usage
>and stack size, either Solaris thread library or Posix thread library?
I'm not familiar with Solaris, but I know for sure that pthreads doesn't
have an interface to do this.
If you're desparate, taking the address of a local variable in a leaf
function is a good estimate.
Why do you want this information? That can give hints about how to
get it indirectly.
>Another question is about alarm and sleep. Posix thread does not support
>per-thread alarm, does it support per-thread sleep() function? How about
>solaris 2.5 thread?
It's unclear whether sleep() is supposed to be thread-safe. My guess is
that such usage is non-portable, and probably unspecified (don't have
my copy of the spec here). Use nanosleep(); it'll always work.
I *really* wish they hadn't standardized the sigaction()/alarm()/pause()
implementation of sleep.
--
Steve Watt KD6GGD PP-ASEL-IA Packet: KD6GGD @ N0ARY.#NOCAL.CA.USA.NA
ICBM: 121W 56' 58.1" / 37N 20' 14.2" Internet: steve @ Watt.COM
Free time? There's no such thing. It just comes in varying prices...
Patrick TJ McPhee
% I'm working on a project on Solaris SPARC 2.5 with Solaris multi-thread
% library. Could anybody shed some light on how to get a thread's memory usage
% and stack size, either Solaris thread library or Posix thread library?
If all else fails, ps has an option that gives per-thread information. I
don't recall what it tells you, but it must (he says) include at least the
memory usage.
--
Patrick TJ McPhee
East York Canada
pt...@interlog.com
Bob_...@transarc.com
"Ying" <yz...@us.oracle.com> writes:
> I'm working on a project on Solaris SPARC 2.5 with Solaris multi-thread
> default. But what I want is the actual stack size or memory a thread
> currently uses when the program is running.
This question comes up pretty often, you might want to check the
archives.
There are at least two methods of obtaining this information. First,
you can initialize each thread's stack using an obscure value
(e.g. 0xbaddbeef) before the thread starts running, and then either at
certain points during the thread's execution or at the point when each
thread is about to exit, scan the stack to see how much is used.
Second, you can try to statically examine the functions your threads
are going to call and calculate the stack they consume.
Both of these approaches have advantages. Initializing/scanning the
stack is pretty easy to implement, but it doesn't truly prove how much
stack your program is capable of using in the worst case (it may
discover it, but you'll always have this gnawing feeling that a
customer is going to find the true worst case). Examining the
binaries can give you a more exact notion of the amount of stack that
can be consumed, but it will also reveal some of the most bizarre
recursive relationships between functions - that for all practical
purposes may never occur.
This is something of a pet peeve of mine. As a developer of threaded
software, you're really not given much help on this topic. At the
very least it would be nice of vendors to publish how much stack space
each function they provide uses in the worst case (like on man
pages).
> Another question is about alarm and sleep. Posix thread does not support
> per-thread alarm, does it support per-thread sleep() function? How about
> solaris 2.5 thread?
Under Solaris, sleep() is per-thread.
-bob
Dave Butenhof
Bob_...@transarc.com wrote:
> This is something of a pet peeve of mine. As a developer of threaded
> software, you're really not given much help on this topic. At the
> very least it would be nice of vendors to publish how much stack space
> each function they provide uses in the worst case (like on man
> pages).
While it sounds nice in theory, such documentation would be extremely difficult
to generate, and nearly useless in practice. Why? Because hardly any code is
written in assembler, which means that the stack usage is not under the control
of the developer. Such documentation would need to be generated automatically by
tracing call paths and adding information output by the compiler (possibly the
binary itself) to come up with worst case (and, presumably "normal") stack usage
for each possible call tree. And the information could change, dramatically, each
time the code was recompiled. Because it can change, the information would be
essentially useless.
> > Another question is about alarm and sleep. Posix thread does not support
> > per-thread alarm, does it support per-thread sleep() function? How about
> > solaris 2.5 thread?
>
> Under Solaris, sleep() is per-thread.
POSIX requires that sleep() be thread-safe, (and, yes, that means that sleep()
must be "per-thread"), but it doesn't say anything about the implementation.
Usually, a modern sleep() uses a synchronous timed delay function, such as
usleep() or nanosleep(), (it could even use select(), or poll(), or
pthread_cond_timedwait()), rather than using SIGALRM and pause().
/---------------------------[ Dave Butenhof ]--------------------------\
| Digital Equipment Corporation bute...@zko.dec.com |
| 110 Spit Brook Rd ZKO2-3/Q18 http://members.aol.com/drbutenhof |
| Nashua NH 03062-2698 http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----------------[ Better Living Through Concurrency ]----------------/
Bob_...@transarc.com
Dave Butenhof <bute...@zko.dec.com> writes:
> While it sounds nice in theory, such documentation would be extremely
> difficult to generate, and nearly useless in practice. Why? Because
> hardly any code is written in assembler, which means that the stack
> usage is not under the control of the developer.
My point is that while developers can't always control the stack
usage dictated by the compiler, they are in fact *responsible* for
allocating enough stack space to ensure correct performance of their
programs. This responsibility is placed upon us by the pthread
interface, which requires we specify the stack size, or accept the
default. This responsibility leads to the question of how much stack
(in the worst case) our code can use. Unfortunately, there's no
standard method of making this calculation - I think there should be
one.
> Such documentation
> would need to be generated automatically by tracing call paths and
> adding information output by the compiler (possibly the binary itself)
> to come up with worst case (and, presumably "normal") stack usage for
> each possible call tree.
Exactly. I have even written a perl script that drives dbx under
Solaris to perform this calculation. It isn't perfect, but it does do
a decent job of identifying the amount of stack used. I have no idea
how difficult it would be to write a similar utility for other
platforms, but for the sparc architecture it's relatively easy since
the convention is to allocate all necessary stack space upon entering
a function (assuming that the code doesn't use alloca - which is
documented as thread unsafe).
Perhaps for other platforms, this calculation is much more difficult.
> And the information could change,
> dramatically, each time the code was recompiled. Because it can
> change, the information would be essentially useless.
So maybe I was a little overzealous in saying stack usage ought to be
chiseled onto man pages. However, I still disagree. Since stack
usage is subject to such dramatic changes (via a patch say) this is
precisely why I think it is critical that developers have access to
this information.
-bob
Steve Watt
In article <MpIOkJGSM...@transarc.com>, <Bob_...@transarc.com> wrote:
[ sneck -- pthreads requires stack size specification, but there's no way
to get the data about what library functions require ]
This thread brings up a question in my mind: Is there really any stack
memory that gets allocated (ignoring pthread_attr_{g,s}etstackaddr,
which is ugly) upon thread creation in any major OS?
I'd imagine that it would only allocate virtual space, and fault in
pages to back it as needed.
So specify a stack size that's *big* -- it won't hurt, under most
implementations. If you're memory constrained, and your vendor doesn't
fault it in, complain.
Virtual address space is virtually free. ;)
Jeff Denham
Steve Watt wrote:
> In article <MpIOkJGSM...@transarc.com>, <Bob_...@transarc.com> wrote:
> [ sneck -- pthreads requires stack size specification, but there's no way
> to get the data about what library functions require ]
>
> This thread brings up a question in my mind: Is there really any stack
> memory that gets allocated (ignoring pthread_attr_{g,s}etstackaddr,
> which is ugly) upon thread creation in any major OS?
>
> I'd imagine that it would only allocate virtual space, and fault in
> pages to back it as needed.
>
> So specify a stack size that's *big* -- it won't hurt, under most
> implementations. If you're memory constrained, and your vendor doesn't
> fault it in, complain.
>
> Virtual address space is virtually free. ;)
Not always true! On systems that back virtual allocations with
swap space, a really big stack will severly limit the number
threads you can create (for one thing). To support huge thread
stacks efficiciently, you need help from the VM subsystem to manage
the swap space issues efficiently as well. Some systems have or
will soon have (Digital UNIX) these specialized thread stacks.
_______________________________________________
Jeff Denham (jde...@brighttiger.com)
Bright Tiger Technologies
SmartCluster™ Software for Distributed Web Servers
http://www.brighttiger.com
125 Nagog Park
Acton, MA 01720
Phone: (978) 263-5455 x177
Fax: (978) 263-5547
Ke Jin
In <EsML4...@Watt.COM> st...@Watt.COM (Steve Watt):
: This thread brings up a question in my mind: Is there really any stack
: memory that gets allocated (ignoring pthread_attr_{g,s}etstackaddr,
: which is ugly) upon thread creation in any major OS?
:
: I'd imagine that it would only allocate virtual space, and fault in
: pages to back it as needed.
:
: So specify a stack size that's *big* -- it won't hurt, under most
: implementations. If you're memory constrained, and your vendor doesn't
: fault it in, complain.
:
: Virtual address space is virtually free. ;)
This depends the thread implementation. You are right for Solaris UI
thread which is indeed implemented as what you expected above. The
Solaris doc says:
... [By default,] the threads library allocates one megabyte of
virtual memory for each thread's stack with no swap space reserved.
(The library uses the MAP_NORESERVE option of mmap(2) to make the
allocations.)
Ke
: --
:
:
Steve Watt
In article <3553213B...@brighttiger.com>,
Jeff Denham <jde...@brighttiger.com> wrote:
>Steve Watt wrote:
>
>> I'd imagine that it would only allocate virtual space, and fault in
>> pages to back it as needed.
>>
>
>swap space, a really big stack will severly limit the number
>threads you can create (for one thing). To support huge thread
>stacks efficiciently, you need help from the VM subsystem to manage
>the swap space issues efficiently as well. Some systems have or
>will soon have (Digital UNIX) these specialized thread stacks.
Why on earth would the virtual allocation *ever* be backed? That means
that the entire virtual address space would be backed, which doesn't
make sense (4GB of swap space *per process*?!?).
After all, on most (all, I think) Unix systems, the first thread in the
process has a basically unlimited stack before the second thread is
created; virtual pages certainly haven't been allocated for that huge
available address space.
If a system supports dynamic stack growth in a single-threaded process,
then the VM system is already up to supporting huge thread stacks; it
knows how to dynamically assign virtual pages to back up stack growth.
sfi...@cc.gatech.edu
I'm currently working on a project for a class where we have to checkpoint a
thread, so that execution can be resumed at a later point. We have to save the
thread's stack to a file. You can get the address of the thread's stack base
with the function "thr_stksegment" and then obtain the stack pointer value by
"getcontext". You then have the top and bottom of the stack. Just subtract one
from the other to get the stack size. Hopefully this helps.
Rick Presley
Richard...@gtri.gatech.edu
Ying wrote:
> Hello there,
>
> I'm working on a project on Solaris SPARC 2.5 with Solaris multi-thread
> library. Could anybody shed some light on how to get a thread's memory usage
> and stack size, either Solaris thread library or Posix thread library?
> thr_stksegment() gives the stack size allocated to a thread, which is 1M by
> default. But what I want is the actual stack size or memory a thread
> currently uses when the program is running.
>
> Another question is about alarm and sleep. Posix thread does not support
> per-thread alarm, does it support per-thread sleep() function? How about
> solaris 2.5 thread?
>
> Thanks in advance.
>
> Ying