[uClinux-dev] Threading and synchronization questions
vapier at gentoo.org
Fri Feb 27 02:08:03 EST 2009
On Thursday 26 February 2009 23:57:28 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.
you mean Linux w/out a MMU. generally, attempting to outright abuse the
general notion that a no-mmu system does not provide inter-process protection
(which is not true for all no-mmu systems btw) and that everyone shares the
same address space is very bad taste and indicates poor/wrong coding/design.
instead of thinking "gee, what can i get away with", figure out how to do it
right. things will be a lot stabler in the long run, and people will be more
likely to assist. people in the open source world are not known for assisting
> 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)
you're basing your data on the output of `ps` ? well that's wrong on so many
while the older linuxthreads implementation resulted in unique pid's for every
thread, that doesnt mean they're the same thing. many resources are tracked
together by the kernel. if a thread is killed or causes a crash, the whole
process will of course go down.
> then what can it be, that would make pthread_mutex not work?
using pthread functions after a vfork and before execve() is wrong. dont do
it. it isnt supported and most likely wont work and if it doesnt work, then
that's a feature.
> 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 version doesnt matter in any of the questions you've asked
> >> 5) There is no dynamicaly-loaded-library (DLL, or .so, or whatever)
> >> support.
> > Depends on your architecture. Some arches haven't implemented it; others
> > have implemented a fairly
> > rudimentary version of shared libraries, still others have full support.
> My architecture is Arm940T (S3C2500B board) running 2.4.22-uc0 kernel,
> provided by Moxa.
> I just found a line in their (IMHO far from complete) documentation that
> says no, no shared libraries.
i do not believe the ARM no-mmu port has a FDPIC ELF implementation. there is
probably shared flat support, but shared flat is awful. just accept that
there is no shared library support and things will be easier.
> >> 9) Or is my approach of multiple processes otherwise flawed? My
> >> intension is
> >> to minimize memory and disk footprint by including only components
> >> necessary
> >> for particular application. Have I other option than to write big
> >> monolithic
> >> process?
> > You could create a server process that accesses the database, and smaller
> > client processes that talk
> > to it (via sockets, files, pipes, or one of the standard shared memory
> > interfaces).
> 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.
umm, why do you think writes are atomic ? POSIX states that read/write
functions need not be atomic. if you want threading synchronization
mechanisms, then use the things designed for exactly that.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the uClinux-dev