Hi,

is it safe to allocate memory(malloc) for some data and then create a pthread with this data and later in the new pthread free the memory?


like this:
void* func2(void* data)
{

.... free(data);
}

void func1()
{
...data = .... malloc...
... pthread_create(..., func2, data);
}


How do i call a certain object in another thread? Do i store obj pointer in a global variable? Are instances shared memory among threads?

Im little confused about threads!

It is safe, as long as no thread attempts to access the memory during or after the free() call. You can free() a pointer allocated using malloc() in any thread -- there is no need to do that in the same thread at all --, as long as you make sure no thread attempts to access the memory during or after the free().

All you need is a pointer to the other object.

That should work. Note that doing that is usually not thread-safe, unless you protect accesses to the global variable with a mutex, or use atomic operators (__sync_bool_compare_and_swap) provided by GCC and most other recent C compilers when modifying the global variable.

All threads see the same memory space. Whatever memory one thread sees, another thread sees at the same address (pointer), exactly the same way.

In addition, you should pthread_cleanup_push(&free, data); with the new pointer. Instead of an explicit free you would use pthread_cleanup_pop(1);, provided you haven't pushed any more handlers on top of that mentioned. Of course, you don't really need all this if you plan to never cancel a thread in your program, now or in the future. You also need a free after pthread_create if thread creation fails, whether or not you use cancelation.
Kevin Barry

Thanks for the explanations and for good tips.

If you are freeing a shared memory object, you should have some kind of mutual-exclusion mechanism surrounding the operation: a thread must acquire the mutex, free the memory, set the pointer that referred to it to NULL, then release the mutex.

(The "extra step" of setting the pointer value to NULL is not accidental. I firmly believe that a pointer's value should always be "known good." If it points to something, that object should be known good; otherwise, it should be null. The value should never be "stale." Take the extra time at startup of initializing all pointer tables to binary zeroes. Also take the extra time to use calloc() to allocate memory blocks and set them to known-zero. You'll be glad you did. It never hurts to allocate a couple extra unused known-zero bytes at the end of a data-structure, either ...)

In general, access to all shared memory structures (or any other sort of shared resource) should be protected by a mutual-exclusion mechanism. For instance, you can use a "read-many write-once" type of mechanism to allow many threads to secure the simultaneous right to read the data structure (thus maintaining stability and data-integrity), and for one thread at a time to secure the right to modify it. Otherwise, in the general case, you can never quite be sure if someone might not be harboring a pointer to something and another thread frees it ... or two threads race to pick up a pointer and both try to release it at the same time, and so on.

In general, the key to designing bulletproof multi-threaded applications is to be very cautious and disciplined about this issue, no matter exactly what the shared resource is.

I realize that this is all ready solved. I make it a point to always free memory in the same thread in which it was allocated. This makes it easier to tell that the memory was freed when reviewing the code. This also assures that a child thread can not free memory before a sibling thread is finished using it.

All threads share access to the memory allocated in the parent thread, so it is necessary to use mutex for data access.

The spawning thread usually needs to use a semaphore set at thread creation and adusted by every spawned thread after the child thread's last access of the memory to guarantee that all child threads have completed before freeing the memory.