Programming

hello,
I have wrote a multi thread application to run under uclinux.
the problem is that threads does not share data. using the ps command it shows a single process for each thread.

I test the application under Ubuntu 8.04 and Open Suse 10.3 with 2.6 kernel and there were no problems and also ps command does not shows a single process for each thread.

but testing the application on Open Suse 9 with 2.4 kernel cause the same problem.

uclinux kernel is also 2.6.

any idea?

The Linux 2.4 kernel used linuxthreads, an odd threading implementation the new 2.6(and some 2.5) kernels made obsolete. Threads were effectively separate processes, but like you'd expect threads to do nearly all memory was shared including stack and heap space. This was managed from userpace through creative use(some say abuse) of the linux "clone" system call. Some things were synchronized with realtime signals which was inefficient, conflicted with some existing RT signals, and had incurable bugs, hence the push to write a better threading system from scratch: NPTL for "native POSIX threading library". The move from linuxthreads to NPTL involved huge changes in glibc and new extensions to the kernel.

Sounds like ulibc still uses the old threading model. They may have aschewed NPTL to reduce code size. The old linuxthreads system will probably work with most any kernel since the clone() system call still exists -- it's used for non-threading process cloning too so they shan't get rid of it. You're probably hitting quirks in linuxthreads that can be worked around, but without seeing the code it's hard to say.

i have tried this simple code and didn't get answer:

Code:

int lock =0;

void* thread1(){
	while(lock);
	
	//some actions ....

	lock =1;
	return 0;
}

void* thread2(){
	while(!lock);
	
	//some actions ....

	lock =0;
	return 0;
}

in thread2(), lock is always 0!

Try 'volatile int lock'. If you're going to modify a variable out from under something else in mysterious ways like threading or memory poking, you have to tell the compiler so. Otherwise it feels free to optimize it away on the assumption that it won't change until it changes it itself.

You should really be using mutexes, though.

thanks,

yes, that was just an example that i used to test the threads behavior.

so the mutexes and any other data that i want to be shared must be defined as volatile, am i right?

That 'lock' integer at the very least needs to be volatile.

Yes, you should use mutex. volatile alone (along with atomic operation) is not enough to guarantee correctness in multi-threaded program. The magic word here is: memory visibility. Interested readers might want to read: Mutex and Memory Visibility

Cheers,
Loïc.

---------- Post updated at 10:15 AM ---------- Previous update was at 10:07 AM ----------

No, absolutely not. As long as you use mutex correctly, there is no need to declare the variables (or the mutexes) volatile.

On a conforming POSIX platform, the compiler shall "know" how to deal with that kind of issue as long as you follow the memory visibility rules given in XBD 4.11 of IEEE Std 1003.1-2008.

Cheers,
Loïc.