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
- 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
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
You've got to be a LOT more careful with memory
than you are probably used to on a windows or "full blown" UNIX
- 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
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 firstname.lastname@example.org list server http://www.uClinux.com/
This message resent by the email@example.com list server http://www.uClinux.com/
This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:38 EST