Memory leak when using detached threads

Hello,
I have a program which creates deatached threads. When I
run it with valgrind I get the following message:
==25935== 544 bytes in 4 blocks are possibly lost in loss record 1 of 1
==25935== at 0x4020681: calloc (vg_replace_malloc.c:279)
==25935== by 0x400F93A: (within /lib/ld-2.4.so)
==25935== by 0x400F9E4: _dl_allocate_tls (in /lib/ld-2.4.so)
==25935== by 0x41A2BB6: pthread_create@@GLIBC_2.1 (in /lib/tls/i686/cmov/libpthread-2.4.so)
==25935== by 0x804E1B9: main (rp_main.c:301)

line 301 is where pthread_create() is called.
My only idea of what this can be caused by is that the
threads are somehow killed without being deallocated properly. Maybe the main program finishes before the
thread resources are deallocated but i dont know if this is
possible.

The way I check for finished threads is a global variable
which holds the number of running threads. An exiting
thread decreases the variable by 1 at the end (with a mutex
locked) and the main program quits when it gets to 0.

My question is if this is a good approach or if it can cause this valgrind behaviour. Any help would be
appreciated.
Thank you,
Michal

There can be all sorts of timing holes. If you care when the threads have finished, then the threads probably should not be detached threads at all.

In my experience, asking threads to own and to manage their own resources is usually a recipe for trouble anyway. As is creating a "potentially unlimited" number of threads.

I'd generally structure the program this way:

• The main thread initializes the environment, then creates a fixed pool of worker-threads.
• The worker-threads wait for work (or a termination indicator), do the work, and repeat... staying alive all the time. (A work-queue may build up fron time to time, but the number of employees remains constant.)
• When it's time to go home, the main thread sends an appropriate indication to all of the children, asking them to terminate themselves.
• The main thread then reaps (joins) each thread, continuing this process until all of the dead bodies have been reaped. (Note that no signal is required to indicate that a child has died.)
• The main program cleans up the environment and exits.

"Be nice to your kids." If you structure the program so that things are too asynchronous, and there's a lot of birthing and dying going on, you've got something that's very tough to debug. Very tough to make reliable...