[uClinux-dev] Threading and synchronization questions
gavinl at compacsort.com
Thu Feb 26 22:02:23 EST 2009
Quoth Jan Ringoš:
> 1) If properly synchronized I can access data of other processes.
True only for !MMU, but it's bad style. You should use the normal shared memory facilities, just as you would on
> 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.
> 4) Can pthread mutexes be used across vfork/exec sub-processes?
> In documentation to pthreads they say that the pthread_mutex can be used to
> synchronize threads but not processes. But I see no difference between
> thread and process in uClinux. What am I missing?
That there really is a difference.
> 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.
> 6) Vfork does not copy any data/code from the old process to the new one, or
> does it? The real question is, will some pointer carried to the new process
> always point to a data in the old process.
With vfork (and unlike fork) the address spaces of the two processes are exactly identical -- changing a value in one
process will change the value in the other process as well, which is why the parent process is halted while the child is
running, to avoid corrupting the stack.
> 7) For data variety, I decided to use a SQLite database. In my current
> design, there will be more separate processes running and using the
> database. But the footprint of the SQLite is relatively large. Provided that
> my code will comply to the threading limitations documented by SQLite, can I
> have it loaded just in single core process, and accessed by other processes?
> SQLite uses pthreads for synchronization.
It might be possible, but I wouldn't go there.
> 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
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).
More information about the uClinux-dev