Unix Programming - What's going wrong ?

This is Interesting: Free IT Magazines  
Home > Archive > Unix Programming > February 2005 > What's going wrong ?





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author What's going wrong ?
Kelvin Moss

2005-02-23, 7:54 am

Hi group,

I have a piece of code in which I want to create 1000 threads and do
some processing after all are created. The code is coring and I am not
sure why. Here is the code --

<CODE>

#include<stdio.h>
#include<stdlib.h>
#include<pthread.h>
#include<sys/types.h>
#include<sys/ipc.h>
#include<sys/sem.h>
#include<sys/shm.h>

pthread_mutex_t condition_mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t condition_cond = PTHREAD_COND_INITIALIZER;
pthread_mutex_t buf_mutex = PTHREAD_MUTEX_INITIALIZER;


static int all_created = 0;
#define KEY 4
#define SKEY 3

int sem_id, shared_id;
struct sembuf buf[1]={0, 1, 0};

void * perfthread()
{
/* Block till all threads are created */

pthread_mutex_lock( &condition_mutex );
while(all_created == 0)
{
pthread_cond_wait(&condition_cond, &condition_mutex );
}
pthread_mutex_unlock(&condition_mutex);

/* Try to grab semaphore */

pthread_mutex_lock(&buf_mutex);
buf[0].sem_op = -1;
if(semop(sem_id,buf,1)==-1) {
perror("semop");
pthread_exit(NULL);
}
printf("Grabbed the semaphore\n");

/* Now release */
buf[0].sem_op = 1;
if(semop(sem_id, buf, 1)== -1) {
perror("semget in thread");
pthread_exit(NULL);
}
printf("Releasing the semaphore\n");
pthread_mutex_unlock(&buf_mutex);
printf("Done...\n");
}

int main()
{
pthread_t thread[100];
int i = 0;
pthread_attr_t tattr;

if ((sem_id=semget(SKEY,1,IPC_CREAT|0640))< 0) {
perror("semget");
exit(1);
}
buf[0].sem_op = 1;
if (semop(sem_id, buf, 1)== -1) {
perror("semop");
exit(1);
}
if((shared_id = shmget(KEY, 1000, IPC_CREAT|0640))<0)
{
perror("shmget");
exit(1);
}
pthread_attr_init(&tattr);
ret = pthread_attr_setdetachstate(&tattr,PTHREAD_CREATE_DETACHED);

for (i = 0; i < 1000; ++i)
pthread_create(&thread[i], &tattr, &perfthread, NULL);
printf("Created all threads\n");

all_created = 1; /* let threads fight now */
pthread_mutex_lock(&condition_mutex );
pthread_cond_broadcast( &condition_cond );
pthread_mutex_unlock( &condition_mutex );


printf("so far so good...\n");
shmctl(shared_id, IPC_RMID, 0);
shmctl(sem_id, IPC_RMID, 0);
exit(0);
}
</CODE>

The code is half-baked but still demonstrates the problem. Any ideas ?

Thanks in advance.

John Smith

2005-02-23, 6:01 pm

One obvious problem is that your array for thread handles isn't large
enough.

> pthread_t thread[100];


> for (i = 0; i < 1000; ++i)
> pthread_create(&thread[i], &tattr, &perfthread, NULL);


-- John


Christian Panten

2005-02-23, 6:01 pm

Kelvin Moss wrote:

> Hi group,
>
> I have a piece of code in which I want to create 1000 threads and do
> some processing after all are created. The code is coring and I am not
> sure why. Here is the code --


[...]
>
> int main()
> {
> pthread_t thread[100];

[...]
> for (i = 0; i < 1000; ++i)
> pthread_create(&thread[i], &tattr, &perfthread, NULL);
> printf("Created all threads\n");

[...]

> </CODE>
>
> The code is half-baked but still demonstrates the problem. Any ideas ?
>
> Thanks in advance.



You have only define an arrow of 100 (one hundred) thread. But the for-loop
where you create the threads calls 1000 (ont thousand) pthread_create().
The program ends at this point (where i == 100) with an segmentation fault.

How can you detect such errors:
Run it in a debuger: I used gdb.

Best regards Christian


Btw: The variable ret is not defined...

Paul Pluzhnikov

2005-02-23, 6:01 pm

Christian Panten <panten@or.uni-bonn.de> writes:

> You have only define an arrow of 100 (one hundred) thread. But the for-loop
> where you create the threads calls 1000 (ont thousand) pthread_create().


Your diagnosis of the problem is correct ...

> The program ends at this point (where i == 100) with an segmentation fault.


But I can't imagine any machine on which the program will really
end with i==100. Did you actually run this and *observe* this
crash with 'i==100' (if so, which OS did you use?), or are you just
hypothesizing that it will?

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

2005-02-23, 6:01 pm

One question... why 1000 threads? thats really alot of threads. If the
threads are doing something very similar I really think theres some ways to
optimize your program to get better efficiency. If you have only 1 cpu in
your system you won't have any performance increase by using more then a few
threads.

I think my linux dist currently uses only like 3-400 threads for the whole
system...

-- John


Christian Panten

2005-02-23, 6:01 pm

Paul Pluzhnikov wrote:

> Christian Panten <panten@or.uni-bonn.de> writes:
>
> But I can't imagine any machine on which the program will really
> end with i==100. Did you actually run this and *observe* this
> crash with 'i==100' (if so, which OS did you use?), or are you just
> hypothesizing that it will?



I have done a test. You are right. At my machine the test-program stops with
i = 595 without using any debugger or memchecker. So the 100 were
hypothesizing. The version of valgrind we have installed can only handle
100 threads, so the last thread has the number 97 (this is not helpfull in
this context).

Best regards
Christian


Kelvin Moss

2005-02-24, 7:52 am


John Smith wrote:
> One question... why 1000 threads? thats really alot of threads. If

the
> threads are doing something very similar I really think theres some

ways to
> optimize your program to get better efficiency. If you have only 1

cpu in
> your system you won't have any performance increase by using more

then a few
> threads.


No, I am trying to mimic a real life scenario of a problem. It is part
of performance measurement problem and not part of some real solution.

Thanks a lot to all. The problem got solved.

Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com