[uClinux-dev] Threading and synchronization questions

Jamie Lokier jamie at shareable.org
Sat Feb 28 14:26:02 EST 2009


Jan Ringoš wrote:
> From: "Gavin Lambert" <gavinl at compacsort.com>
> >Quoth Jan Ringoš:
> >>3) There is no practical distinction between process and thread in 
> >>uClinux
> >>as there is in Windows world.
> >
> >Untrue.  Just as on Windows, processes have separate address spaces 
> >(normally) while threads
> >have shared address spaces, and threads are owned by processes.  The main 
> >distinction between
> >Windows and Linux in this regard is that processes are significantly 
> >cheaper to create in Linux
> >than under Windows, but processes are still heavier than threads.
> 
> Well, I am interested in uClinux only, in this case. I still don't see the 
> difference. If all the processes live in the same address space here, and 
> when I create a thread (pthread_create) I see a new duplicate process 
> through ps command (just as if created by vfork), then what can it be, that 
> would make pthread_mutex not work?

On uClinux, processes don't live in the same address space logically.

It _looks_ like one address space because there's no protection or
remapping - often you can access memory of a different process using
a pointer from the other process.

But if you look closer, there's more to an "address" than the 32 bits
of a pointer.  Pointers are sometimes deferenced with a process
context, in the form of XIP/PIC registers or the TLS register.  That
means you can't _always_ use pointers from another process.

This is clear when code is compiled with XIP - which you can do on ARM
too.  It's also more obvious with FDPIC-ELF.

> I am sorry, maybe I am little slow here. Feel free to stop me if I am 
> challenging some immutable truth :-) I do recall reading something about 
> changes from kernel 2.4 to 2.6. I am not sure what it was exactly, but I 
> should get my hands on 2.6 kernel version of the device soon.

The kernel doesn't make any difference to your questions.
2.4 to 2.6 does make a lot of difference to other things, though :-)
Use 2.6 if you can, it's much better in most ways.
However, there are some problems with no-MMU memory fragmentation
(reported here recently) which haven't been fixed in 2.6 yet.

> I think I can use the pipes (with their atomic writes) to get rid of any 
> use of mutexes in this case. But it will be otherwise a little more 
> complicated than just calling the exposed functions.

If you just call the exposed functions, you'll have all sorts of
problems when you port your code to another platform - including the
same chip with different GCC options.  It's a bad idea, even though
it's easy.

-- Jamie



More information about the uClinux-dev mailing list