threads / malloc / free / global array

[hipek99]

look at this:

#define _REENTRANT
#include <stdio.h>
#include <pthread.h>
#include <stdlib.h>

struct _str *array[10000];
struct _str
{
int a;
char b[1000];
};

void t1()
{
int i=0;
for(i=0;i<10000;i++)
{
array = (struct _str*)malloc(sizeof(struct _str));
}
printf("malloc\n");
pthread_exit(NULL);
}

void t2()
{
int i = 0;
sleep(10);
for(i=0;i<10000;i++)
free(array);

printf("free\n");
pthread_exit(NULL);
}

main()
{
pthread_attr_t attr;
pthread_t t;

pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr,PTHREAD_CREATE_DETACHED);

pthread_create(&t,&attr,(void *)t1,NULL);
pthread_create(&t,&attr,(void *)t2,NULL);
sleep(20000);
}

why can't I free memory in t2 allocated in t1
if I remove pthread_exit(NULL) in t1 memory would be free

in a nutshell: I allocate global memory in one thread, then end this
thread, then free global memory in second thread, and when I look at
'ps aux' I notice that memory wasn't free

thanks for advice
hipek99

 

[CBFalconer]

look at this:

#define _REENTRANT

Invading the system namespace area

#include <stdio.h>
#include <pthread.h>

No such header in standard C

#include <stdlib.h>

struct _str *array[10000];

Again, invading the system namespace area

Which is quite enough to show that the remainder is pointless, and
that you are off-topic here, where we discuss only the standard C
language.

 

[Gordon Burditt]

in a nutshell: I allocate global memory in one thread, then end this

thread, then free global memory in second thread, and when I look at
'ps aux' I notice that memory wasn't free

free() is not guaranteed to return memory back to the OS, any more
than excess hamburger is guaranteed to be returned to the farm where
the cow was raised. Holding on to the memory for later allocation
is generally considered an optimization. Some UNIX variants simply
have no way to return memory back to the OS, other than exiting the
process (with exit() or abort(), among other ways of terminating a
process).

Gordon L. Burditt

 

[Keith Thompson]

in a nutshell: I allocate global memory in one thread, then end this
thread, then free global memory in second thread, and when I look at
'ps aux' I notice that memory wasn't free

free() makes memory available for further allocation; it doesn't
necessarily deallocate it in a way that's going to be visible to
"ps aux".

Threads are not defined in standard C, and therefore are off-topic
here, but you might try running a small program that allocates and
frees a chunk of memory without using threads. I suspect that
"ps aux" (which is also off-topic here) won't show that it's been
deallocated. A subsequent malloc() in the same program might (or
might not) grab the same chunk of memory.

 

[Old Wolf]

in a nutshell: I allocate global memory in one thread, then end this
thread, then free global memory in second thread, and when I look at
'ps aux' I notice that memory wasn't free

To conform to the C standard you must free memory in the
same thread that you allocated it.
If you think that your platform should allow you to free
memory from different threads then you should ask your
question on a newsgroup specific to your platform, eg.
comp.unix.programmer

 

[Keith Thompson]

To conform to the C standard you must free memory in the
same thread that you allocated it.
If you think that your platform should allow you to free
memory from different threads then you should ask your
question on a newsgroup specific to your platform, eg.
comp.unix.programmer

Um, not exactly. To conform to the C standard you shouldn't use
threads at all. The question of whether you can allocate memory in
one thread and free it in another is outside the scope of the C
standard. So is the question of whether you can allocate and free
memory in one thread while another thread is running.

Threads are an extension to the language. Any interaction between C
memory allocation and threads has to be defined by whatever defines
the extension.

(As I posted earlier, I suspect the actual problem is unrelated to
threads -- but the OP never came back and told us what he found out.)

 

[Giovanni]

Um, not exactly. To conform to the C standard you shouldn't use
threads at all.

This is ridicolous. You are saying that I should not write programs if
I want to conform to the standards.

Threads are an application that is going to be part of my program.

The question of whether you can allocate memory in
one thread and free it in another is outside the scope of the C
standard. So is the question of whether you can allocate and free
memory in one thread while another thread is running.

This is true and probably should be discussed in another N.G.

Threads are an extension to the language. Any interaction between C
memory allocation and threads has to be defined by whatever defines
the extension.

In my opinion threads are an extension to the OS

(As I posted earlier, I suspect the actual problem is unrelated to
threads -- but the OP never came back and told us what he found out.)

Ciao
Giovanni

 

[Lawrence Kirby]

This is ridicolous. You are saying that I should not write programs if
I want to conform to the standards.

A better way to look at it is that you can't write all programs in
standard C. If you want to use threads you'll need to use some sort of
extension, which might be in the form of another standard. There is a
tradeoff between portability and functionality. Standard C is the most
portable i.e. it will run on the broadest range of platforms. Using
extensions will limit portability to those platforms that support them.
There are advantages to being portable where you can, but sometimes you
can't or the tradeoffs are just too severe.

Threads are an application that is going to be part of my program.

That's fine, it just means you have to go beyond standard C and you will
limit the platforms your code will run on. Presumably that won't be a
problem in your case.

It does mean of course that there will be aspects of your program that
can't be discussed in comp.lang.c, which you may or may not consider a bad
thing.

This is true and probably should be discussed in another N.G.
Exactly.


In my opinion threads are an extension to the OS

It doesn't make much difference, where they exist they are a feature of
the environment the program runs in. They may be an inherent part of the
OS, an extension provided by the C implementation, a 3rd party library or
whatever. It's not important.

Lawrence

 

[Keith Thompson]

This is ridicolous. You are saying that I should not write programs
if I want to conform to the standards.

No, that's not what I'm saying.

Lawrence Kirby explained what I meant at least as well as I would
have, so I'll leave it at that.

 

[Giovanni]

A better way to look at it is that you can't write all programs in
standard C. If you want to use threads you'll need to use some sort of
extension, which might be in the form of another standard. There is a
tradeoff between portability and functionality. Standard C is the most
portable i.e. it will run on the broadest range of platforms. Using
extensions will limit portability to those platforms that support them.
There are advantages to being portable where you can, but sometimes you
can't or the tradeoffs are just too severe.

Yes sticking to C library makes a program more portable but you can not
say that a program is not following the standard just because it uses a
non ANSI library.

Using a non ANSI library is not an extension to the language.
Is an application of the language.

Lawrence

Ciao
Giovanni

 

[CBFalconer]

Yes sticking to C library makes a program more portable but you
can not say that a program is not following the standard just
because it uses a non ANSI library.

Using a non ANSI library is not an extension to the language.
Is an application of the language.

But we CAN say that you can't ask about the use of that library
here without publishing the complete library source (all written in
standard C) here, in 200 lines or less of no more than 72 chars
each.

 

[Lawrence Kirby]

Yes sticking to C library makes a program more portable but you can not
say that a program is not following the standard just because it uses a
non ANSI library.

I can say that it isn't a strictly conforming program, and more
significant that the behaviour of the program cannot be determined from
the C language. I can say that something that legitimately calls itself a
C compiler can reject the program. I might then being to question to what
degree the statement that the code is "following the standard" is helpful.

Using a non ANSI library is not an extension to the language.
Is an application of the language.

The non-standard library is by definition not part of the standard
language. That makes it an add-on, an extension.

Lawrence

 

[Giovanni]

I can say that it isn't a strictly conforming program, and more
significant that the behaviour of the program cannot be determined from
the C language. I can say that something that legitimately calls itself a
C compiler can reject the program. I might then being to question to what
degree the statement that the code is "following the standard" is helpful.




The non-standard library is by definition not part of the standard
language. That makes it an add-on, an extension.

Very questionable.

Lawrence

Ciao
Giovanni

 

[Lawrence Kirby]

Very questionable.

Or, from another viewpoint, rather obvious. I really see no reason why
this would be considered questionable.

Lawrence

 

[Giovanni]

Or, from another viewpoint, rather obvious. I really see no reason why
this would be considered questionable.

Lawrence

Because I think you are confusing the language and the programs. Or may
be that we give a different meaning to the word "library".

The language standards specify a set of rules on how to write code in
such a way that compilers in different environment can understand it.

#include <threads.h>

is perfectly legal and adhering to the standards as long as the objects
declared in that file use the C language as defined by standards. It
may not be portable to a different environment (where threads are not
supported).

The keywords 'const' and 'inline' were extensions to the language
(supported only by some compilers till they were included in the standards).

Ciao
Giovanni