[uClinux-dev] Threading and synchronization questions

Mike Frysinger 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 
wrong endeavors.

> 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 
levels ...

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.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20090227/b9cd1ec3/attachment.sig>


More information about the uClinux-dev mailing list