Forks: Forked processes may not always have its own copy of ALL the segments of the update engine. Most processes of Linux will do a "copy-on-write" for a "page", i.e. a process will get its own copy of a page only if it modifies it. So the RAM requirement is not high. So the only overhead is creation of the kernel structures. If we have a MMU, the memory consumption of a process may be lower than we think because of the "copy-on-write" semantics. Switching and interprocess communication time is more. But this is not an overhead if there is not very frequent switching and communication between processes, as in our case where each process will execute its own copy of update engine and work on independent patch parts. We do not require any additional libraries to supports forks as in case of threads. The problem of concurrency and synchronization complexity is not evident among processes created with fork. Threads: Linux has a unique implementation of threads. To the Linux kernel, there is no concept of a thread. Linux implements all threads as standard processes. The Linux kernel does not provide any special scheduling semantics or data structures to represent threads. Instead, a thread is merely a process that shares certain resources with other processes. Each thread has a unique task struct and appears to the kernel as a normal process which just happens to share resources, such as an address space, with other processes. Threads are created like normal tasks, with the exception that the clone () system call is passed flags corresponding to specific resources to be shared. This leads to a behavior identical to a normal fork (), except that the address space, file system resources, file descriptors, and signal handlers are shared. In other words, the new task and its parent are what are popularly called threads. This approach to threads contrasts greatly with operating systems such as Microsoft Windows or Sun Solaris, which have explicit kernel support for threads (and sometimes call threads lightweight processes).The name "lightweight process" sums up the difference in philosophies between Linux and other systems. To these other operating systems, threads are an abstraction to provide a lighter, quicker execution unit than the heavy process. To Linux, threads are simply a manner of sharing resources between processes (which are already quite lightweight) Threads require support libraries, so extra space is required in flash memory. If we have to ship just one program that requires the threading library (as in our case the update engine), then we have to ship the threading library. Minimizing the threading library cost is only possible if we can identify all multithreaded programs in the base Linux distribution. Once we have the library in the flash image to support just one such program, it costs "nothing" for additional programs to also link to it. Updation of libraries may also be required so this may increase the installation time. Threads have Moderate RAM requirement but it depends upon number of threads. The advantage of threads is their lower resource consumption. Multiple threads typically share the state information of a single process, and share memory & other resources directly. Though threads share resources, in our case the sharing is not substantial. Threads take much less CPU time to switch among themselves than between processes, because there's no need to switch address spaces. In addition, because they share address space, threads in a process can communicate more easily with one another. Of course inter thread communication can be easier than inter process communication, as we can use shared memory objects, but additional care must be taken to use thread save functions wherever necessary. Another problem is concurrency and synchronization complexity. Sharing, locking, deadlock; race conditions come vividly alive in threads. Processes don't usually have to deal with this, since most shared data is passed through pipes. Threads can share file handles, variables, signals, etc. this may lead to error conditions if not handled properly. Applications executed in a thread environment must be thread-safe. This means that functions (or the methods in object-oriented applications) must be reentrant-a function with the same input always returns the same result, even if other threads concurrently execute the same function. Accordingly, functions must be programmed in such a way that they can be executed simultaneously by several threads.
Threads vs Forks in embedded environment : Some Conclusions
Started by ●September 7, 2006
Reply by ●September 7, 20062006-09-07
Reply by ●September 7, 20062006-09-07
"Abhishek" <abhisheksingh.bits@gmail.com> wrote in message news:1157621131.822946.122460@e3g2000cwe.googlegroups.com...> Plz give ur commentsMy first comment is that your 'e', 'a',' y' and 'o' keys are only working intermittently and that "Please" is spelled with an 's' and not a 'z'.
Reply by ●September 7, 20062006-09-07
Abhishek wrote:> > Plz give ur commentsTo what? What language are you attempting to use? If English, the words are spelled 'please' and 'your'. Childish abbreviations and lack of quotations just make you look foolish and ensure that many will simply ignore you. -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net>
Reply by ●September 7, 20062006-09-07
Abhishek wrote:> Plz give ur commentsI find that forks are very good at picking up threads (particularly spaghetti) while picking up a fork with a thread can de difficult. I would therefore conclude that in a fork versus thread battle the fork will win. Ur was a city in Mesopotamia. As I do not fancy going to Iraq at the moment could you arrange to take my comments there.
Reply by ●September 7, 20062006-09-07
On 2006-09-07, Tom Lucas <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote:> "Abhishek" <abhisheksingh.bits@gmail.com> wrote in message > news:1157621131.822946.122460@e3g2000cwe.googlegroups.com... >> Plz give ur comments > > My first comment is that your 'e', 'a',' y' and 'o' keys are only > working intermittently and that "Please" is spelled with an 's' and not > a 'z'.My comment is that the OP shouldn't multipost. He posted exact same question in at least 3 newsgroups. -- Grant Edwards grante Yow! LOU GRANT froze at my ASSETS!! visi.com
Reply by ●September 7, 20062006-09-07
Grant Edwards <grante@visi.com> writes:> On 2006-09-07, Tom Lucas <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote: >> "Abhishek" <abhisheksingh.bits@gmail.com> wrote in message >> news:1157621131.822946.122460@e3g2000cwe.googlegroups.com... >>> Plz give ur comments >> >> My first comment is that your 'e', 'a',' y' and 'o' keys are only >> working intermittently and that "Please" is spelled with an 's' and not >> a 'z'. > > My comment is that the OP shouldn't multipost. He posted exact > same question in at least 3 newsgroups.You mean he forked the thread? -- John Devereux
Reply by ●September 7, 20062006-09-07
On 2006-09-07, John Devereux <jdREMOVE@THISdevereux.me.uk> wrote:>> On 2006-09-07, Tom Lucas <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote: >>> "Abhishek" <abhisheksingh.bits@gmail.com> wrote in message >>> news:1157621131.822946.122460@e3g2000cwe.googlegroups.com... >>>> Plz give ur comments >>> >>> My first comment is that your 'e', 'a',' y' and 'o' keys are only >>> working intermittently and that "Please" is spelled with an 's' and not >>> a 'z'. >> >> My comment is that the OP shouldn't multipost. He posted exact >> same question in at least 3 newsgroups. > > You mean he forked the thread?No, the OP posted the exact same question individually to 3 different newsgroups that I know of based on the dozen or so that I read. -- Grant Edwards grante Yow! "DARK SHADOWS" at is on!! Hey, I think visi.com the VAMPIRE forgot his UMBRELLA!!
Reply by ●September 7, 20062006-09-07
On 7 Sep 2006 02:10:54 -0700, "Abhishek" <abhisheksingh.bits@gmail.com> wrote:>Threads:>Another problem is concurrency and synchronization complexity. >Sharing, locking, deadlock; race conditions come vividly alive in >threads.OTOH, on any processor with at least some rudimentary atomic instructions, implementing e.g. a critical section is very lightweight as long as there is no conflict (only a few instructions), since the lock variable is in the same address space. Only if there is a conflict, some mode changes will be needed. Paul
Reply by ●September 7, 20062006-09-07
Grant Edwards <grante@visi.com> writes:> On 2006-09-07, John Devereux <jdREMOVE@THISdevereux.me.uk> wrote: > >>> On 2006-09-07, Tom Lucas <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> wrote: >>>> "Abhishek" <abhisheksingh.bits@gmail.com> wrote in message >>>> news:1157621131.822946.122460@e3g2000cwe.googlegroups.com... >>>>> Plz give ur comments >>>> >>>> My first comment is that your 'e', 'a',' y' and 'o' keys are only >>>> working intermittently and that "Please" is spelled with an 's' and not >>>> a 'z'. >>> >>> My comment is that the OP shouldn't multipost. He posted exact >>> same question in at least 3 newsgroups. >> >> You mean he forked the thread? > > No, the OP posted the exact same question individually to 3 > different newsgroups that I know of based on the dozen or so > that I read.Guess I should have used a smiley :) -- John Devereux
