Multithreading problems

[John Clark]

Rich Felker schrieb:
> On Wed, Aug 02, 2006 at 04:49:28PM -0700, John Clark wrote:
>   
>> However, one must always put '<pthread.h> at the beginning of all code 
>> which calls anything
>> having to do with any libc or system call. While there may be some calls 
>> that are by nature 'multithread'
>>     
>
> This is totally unreasonable and not required or recommended by posix,
> and in fact not possible if some of your code modules are plain C and
> not posix/pthread dependent. Are you sure the real issue isn't the
> need for -D_REENTRANT or something similar?
>   

The only quick example I found was how 'signal' was redefined in terms 
of a LinuxThread safe
version, found under the uClibc-0.9.27 pthreads directory.
The other quick reference I found on the web is an old discussion about 
glibc, ca. 1999 when Linuxthreads
were first being supported by glibc:


        C.6: How can I recompile the glibc 2 version of the LinuxThreads
        sources?

You must transfer the whole glibc sources, then drop the LinuxThreads 
sources in the |linuxthreads/| subdirectory, then recompile glibc as a 
whole. There are now too many inter-dependencies between LinuxThreads 
and glibc 2 to allow separate re-compilation of LinuxThreads.

-------------------------


When I see verbage like this, and given the complexity of call paths 
through the libraries, even though uClibc is 'simpler' by some measure 
than glibc,
I get worried, and become very explicit about declaring my intention to 
use pthreaded versions of every thing.

I have not looked at the implementation of say, 'malloc' but I believe 
there may be a threading problem, even with pthread.h included
which causes problems. I can't verify this, but for other reasons I 
basically made my own pthread safe malloc, ie created a malloc_mutex 
variable,
to allow me more debugging visibility in to how my program was 
allocating memory, and crashing after a while due to memory exhaustion.
Now I protect malloc with a semaphore, and count up and down for each 
malloc or free.

As a note, reentrancy is a requirement of multithreading, but it is not 
identical with 'thread-safe'.

John Clark