RE: [uCsimm] phtreads (follow-up) ???

From: Joe deBlaquiere (
Date: Sun Sep 24 2000 - 12:10:25 EDT

I did a port of glibc to uClinux for ARM which included pthreads support.
You could rip this code out of glibc and include it in uClibc, but it would
probably be pretty painful, since it has some hooks back into things like
malloc, exit, etcetera. I would think it might be easier to add support for
the m68k than to cut pthreads out of glibc and paste to uclibc. In either
case, you should be able to get the patch for glibc at It's an old patch so if you really
wanna use glibc, you'll need to bug me and make me generate a new diff which
includes a rather important malloc fix.

And BTW: pthreads works absolutely seamlessly on uClinux! Threaded programs
rule! fork sucks! ;o)

Joe deBlaquiere
Red Hat, Inc. -
307 Wynn Drive
Huntsville, AL 35805
voice : 256-704-9257
fax : 256-837-3839

> -----Original Message-----
> From: []On
> Behalf Of Robert Eugene Wood
> Sent: Friday, September 22, 2000 11:30 AM
> To:
> Subject: Re: [uCsimm] phtreads (follow-up) ???
> Please note upfront that I am fairly new to uClinux/uCsimm. I've
> only been able to play with mine off and on for a couple of weeks
> since the project I bought it for at work has been put on
> the back burner. Also, I
> have only a limited practical knowledge of threads under windows
> and pthreads (I've done some work on both platforms, but nothing
> complex). As such I'll gladly accept criticism/correction if I'm
> off the mark.
> By the way, if you are new to Unix-style IPC programming, I
> highly recommend "Unix Network Programming Volume 2, Second
> Edition, Interprocess Communications" by the late, great
> W Richard Stevens. Volume 1 is also one of the best
> TCP/IP books I've seen.
> That being said, I think there are at least 2 characteristics of
> the uCsimm hardware and uClinux in general that may have a bearing
> on your design and may require some re-engineering of your code
> to accomodate:
> - The CPU is relatively slow (@ 16 Mhz?, motorola 68000)
> - The dragonball CPU on the ucsimm has no MMU!
> I mention the speed issue because if your code includes several
> threads doing some serious crunching, you may want to consider
> another platform up front. Just a word of caution.
> I honestly don't know if pthreads is implemented under uclinux
> (I'm not near my dev platform to check). The OS does allow
> processes however.
> Anyway, the lack of a MMU has far greater implications for
> a threaded design:
> - There is no memory protection between processes and all
> programs (including the kernel) share the same address space:
> In some ways this may help your design. If one of the reasons you
> are using threads is to make shared memory easier, then
> it is trivial to share any memory address between completely
> unrelated processes or programs. Of course, it also means
> that one out of control process can completely bring down the
> whole box.
> You've got to be a LOT more careful with memory
> than you are probably used to on a windows or "full blown" UNIX
> environment.
> - The creation of processes is handled differently. One thing
> that is stressed even in the ucsimm setup manual is that uclinux
> uses vfork rather than fork. The child process has the same
> stack as the parent (which is suspended until the functin returns),
> so for all practical purposes the
> only think you can do with the child is to use it to exec()
> a new process and return.
> The implication for a threaded design (as far as I can guess)
> is that rather than creating several threads from one code base,
> you would exec() several copies of the application (or break
> it into several seperate programs, any one of which you could
> exec() as many times as you need) and use the inherently
> shared memory and other rich UNIX synchronization features
> (semaphores, signals, pipes, etc) to manage them.
> Also, there is equivalent to the Win32 "CriticalSection()" calls
> to aid in synchronization. Semaphores can be easily used
> to duplicate this functionality, though. Hmmm... If uclinux
> does not support named semaphores [anyone?], then sharing
> sempahores between different process may not be as easy
> as I'm assuming... If they don't exist, I'm going to have
> to re-design some code myself!
> Also, if your code dynamically allocates and frees memory a lot
> you can fragment the address space for the whole processor. If
> possible, make your code grab a big block of memory when it
> starts and manage the memory yourself. Remember, everything
> shares the same address space!
> Any comments, corrections, or criticisms will be greatly
> appreciated.
> Robert Wood
> On Thu, 21 Sep 2000, Johan Severeyns wrote:
> > Johan Severeyns wrote:
> >
> > > Hi,
> > >
> > > Did anyone already try to build an application, statically linked
> > > with the pthreads lib ? What trouble could I expect ?
> > >
> > > I read a rather disturbing email in the list about the
> uClinux libc
> > > NOT being thread aware. Is this true ?
> > >
> > > (I am already starting to panic here ...)
> >
> > A little background info:
> >
> > The project I am working on requires me to port a piece of
> > windows Win32 C source to the uCSimm. That piece of code definitely
> > requires threading support.
> > I have got a lot of experience writing threaded
> applications on windows.
> > Linux threading is new to me, but the concept should be the same.
> > I chose pthreads because it seems to be a popular library, however
> > this does not need to be the final choice. Any advice here ?
> >
> > By the way: Is it normal that it takes 3 hours to see my
> own post on the list ?
> > The mail is immediately delivered to your server, as show
> my logs, but it seems
> > to be processed very slowly by the list server.
> > This certainly does make communicating tough along with the
> 7 hours of
> > timezone difference.
> >
> > --
> > Johan Severeyns
> > R&D Engineer, Network Administrator
> > IDCS N.V.
> >
> >
> > This message resent by the list server

This message resent by the list server

This message resent by the list server

This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:38 EST