[uClinux-dev] Threading and synchronization questions
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
> >>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
More information about the uClinux-dev