Jan Ringoš wrote: > From: "Gavin Lambert" <gav...@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 _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
