Multithreading problems

[John Clark]

Marshall Crocker schrieb:
> I did some digging in the uClibc emails and found out that the pthreads 
> library is  linuxthreads  and not NPTL which explains why mutexes 
> wouldn't work and also why I see several threads for my app instead of 
> one.  I also saw that NPTL work is being done for uClibc and should be 
> merged into the main NPTL tree.


I don't usually respond to things on uClibc these days, as I've switched 
over to glibc for various
reasons on the current project.

However, I've used the uClibc + linuxthreads implementation of pthreads 
successfully. The
system ran on an 586 level processor, and had 6-7 'threads' in operation 
using mutex, signals,
etc. for the usual things one does to coordinate mulithreaded applications.

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'
safe, it is too vague, and so making sure all modules call the pthreaded 
versions is assured (unless
something is broken in the library or include files...). So if the 
'curl' package naturally has all of
its modules 'pthread' protected, all is well, otherwise, if they are 
called by some set of the
threads, trouble could result.

The biggest problem I had with threaded apps is the abysmal support gdb 
has for linuxthreads.
I never was able to effectively debug my threaded apps using this 
standard app. I was running
my app on a embedded target, so I was attempting to debug on a host, in 
so far as I could
simulate the target environment...

Ultimately, I resorted to my more 'traditional' method of debugging 
kernel drivers, namely
print statements, or even parallel port bit fiddling until the 'ah ha' 
moment occured.

John Clark