pthread_create and memory

pthread_create and memory

Post by Giorgio Sp » Sat, 12 Mar 2005 19:09:08


Hi,
I hava fedora core 2 linux system with kernel 2.6.5-1.358 and i have
installated the pthread library. I try to use the function pthread_create
().
I done this simplex test:and work fine.
The only problem is that after each new thread the memory of my process in
increased of 10 MB !!! Why ??
Can you hel me please


void *thread_func (void* p)
{
while (1)
{
printf ("ciao\n");
sleep(1);
}
return (NULL);
}

int testthread()
{
int i, numthreads;
int retval;
numthreads = 10;

pthread_t thread_id[10];

for ( i = 0; i < numthreads; i++ ) {
(void) printf( "Thread #%d: ", (i + 1) );
if ( ( retval = pthread_create( &thread_id[i], NULL, thread_func,
NULL ) ) != 0 ) {
(void) fprintf( stderr,
"*** Unable to create thread #%d ***\n",
i );
}
(void) printf( "thread done\n" );
(void) sleep( 1 );
}

return( EXIT_SUCCESS );
}
The thread is created and work fine.
The problem is that the memory of my process is increased from 3Mb to 13 MB
 
 
 

pthread_create and memory

Post by jd » Sat, 12 Mar 2005 19:42:10

> I hava fedora core 2 linux system with kernel 2.6.5-1.358 and i have

Because each thread has it's own stack. In this case it looks like it's size
is one megabyte - that's all.

You can change size of process' stack using pthread_attr_setstacksize()
function.

pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setstacksize(&attr, MY_STACK_SIZE);

pthread_create(&tid, &attr, some_fun, some_arg);

Error checking here and there and everything should be fine.

JD

 
 
 

pthread_create and memory

Post by Gio6 » Sat, 12 Mar 2005 19:55:55

Thank you.I try but nothing change.
Do you have the same problem ?
Is possible that the problem depends from whitch library I use ?

"jd" < XXXX@XXXXX.COM > ha scritto nel messaggio

pthread_create
in
size
 
 
 

pthread_create and memory

Post by Giancarlo » Sat, 12 Mar 2005 20:31:20


Yes, but
What's the size you set as MY_STACK_SIZE ?

Gian.
 
 
 

pthread_create and memory

Post by jd » Sat, 12 Mar 2005 21:40:58

> Thank you.I try but nothing change.

I don't think so. Most probably, as Giancarlo mentioned, you must set
variable (constant) MY_STACK_SIZE to be equar or greater than
PTHREAD_STACK_MIN. On my system it's equal to 16384, no less, no more. Och,
and you should read man page for pthread_attr_setstacksize() of course.

JD
 
 
 

pthread_create and memory

Post by Gio6 » Sat, 12 Mar 2005 21:55:31

Ok,
the problem is that I set the stack size with value <= 16384 !! Now I set
16384 and the memory is OK !!
thank you !!
I have an other request: do you know any api of kernel to know the status of
the threads ??
Bye

"jd" < XXXX@XXXXX.COM > ha scritto nel messaggio

Och,
 
 
 

pthread_create and memory

Post by Bluejac » Sun, 13 Mar 2005 03:45:41


Depending on what you mean by "status" the api you are probably looking
for is pthread_join():

http://www.yqcomputer.com/

It sounds like you could use a decent reference manual. Although it's
not comprehensive, this is a good place to start:

http://www.yqcomputer.com/

-bluejack
 
 
 

pthread_create and memory

Post by David Schw » Sun, 13 Mar 2005 12:00:57


Why do you care? That's *virtual* memory, which should not be a scarce
resource.

DS
 
 
 

pthread_create and memory

Post by David Hopw » Sun, 13 Mar 2005 16:41:20


Unless you have a 64-bit machine, virtual memory *is* a scarce resource.
This is one of the things (only one) that prevents kernel threads from
scaling beyond a few thousand per process on a 32-bit machine or OS.

--
David Hopwood < XXXX@XXXXX.COM >
 
 
 

pthread_create and memory

Post by Sam Siege » Mon, 14 Mar 2005 03:56:37


If your design does not require you to syncronise at thread-end using
pthread_join to reclaim its resources, use the correct combinations of
pthread_attr_init, pthread_attr_destroy and pthread_attr_setdetachstate
to set each new thread to PTHREAD_CREATE_DETACHED before using
pthread_create. In this fashion using pthread_join is not allowed and
system-level thread specific resources assoicated the pthread_create
will be automatically reclaimed at thread-end.

http://www.yqcomputer.com/

Sam
 
 
 

pthread_create and memory

Post by David Schw » Mon, 14 Mar 2005 04:13:18


And the fact that you don't have a few thousand processors.

DS
 
 
 

pthread_create and memory

Post by David Hopw » Mon, 14 Mar 2005 08:50:48


That's beside the point. Threads are primarily for expressing concurrent
program structure. Use of hardware parallelism is a bonus.

--
David Hopwood < XXXX@XXXXX.COM >
 
 
 

pthread_create and memory

Post by David Schw » Mon, 14 Mar 2005 11:03:34


No, tasks are primarily for expressing concurrent program structure.
Threads are for keeping CPUs busy or performing asynchronous I/O. Threads
are how you get the work done, not how describe the work. You should not
have more threads than tasks you can usefully do at the same time, and the
number of things you can usefully do at the same time is how many processors
you have plus how many I/Os you can usefully pend. On typical machines, this
is far less than 100.

DS
 
 
 

pthread_create and memory

Post by David Hopw » Tue, 15 Mar 2005 06:57:19


There doesn't need to be any distinction between threads and tasks.
The fact that there is such a distinction in most current systems is an
implementation artifact, and one that introduces unnecessary complexity.

--
David Hopwood < XXXX@XXXXX.COM >
 
 
 

pthread_create and memory

Post by Giancarlo » Tue, 15 Mar 2005 09:10:00


Threads are agents. Tasks are what agents are supposed to do.

Your programs will run better if you make your agent layout and operational
attitudes to match the ones of the physical hardware they have to use to
perform the tasks. Code may be often de-complexified if the developer is
abstracting the final architecture, but in many occasions agents ARE MEANT
to exploit hardware capabilities; i.e. if I am writing a thread to talk
with the sound board, then that thread and the parallel support for sound
boards (DMA, hardware synthethyzers, coprocessors and so on) will probably
be very akin one to each other; other than multiprocessor computational
power exploting, that's what DS (probably) meant.

But definitely, agents are not tasks. And so, threads are not tasks.
Confusing the two is incorrect: it may cause unnecessary code fuzzyness
and, as I use to say, incorrect code brings bad luck. In MT context, this
means you are going to have some trouble for sure.


Bests,
Giancarlo Niccolai.