Would it make sense to limit the number of threads in a server process?
Yes, for two reasons. First, threads require memory for setting up theirown private stack. Consequently, having many threads may consume toomuch memory for the server to work properly. Another, more serious rea-son, is that, to an operating system, independent threads tend to operate ina chaotic manner. In a virtual memory system it may be dicult to builda relatively stable working set, resulting in many page faults and thus I/O.Having many threads may thus lead to a performance degradation resultingfrom page thrashing. Even in those cases where everything ts into mem-ory, we may easily see that memory is accessed following a chaotic patternrendering caches useless. Again, performance may degrade in comparisonto the single-threaded case.
We described a multithreaded le server, showing why it is better thana single-threaded server and a nite-state machine server. Are there anycircumstances in which a single-threaded server might be better? Give anexample.
Yes. If the server is entirely CPU bound, there is no need to have multiplethreads. It may just add unnecessary complexity. As an example, considera telephone directory assistance number for an area with 1 million people.If each (name, telephone number) record is, say, 64 characters, the entiredatabase takes 64 megabytes, and can easily be kept in the servers memoryto provide fast lookup.
Compare threads and Processes.
Multithreading leads to performance gain(creation and switching arefaster)
A multithread system maintains minimum information in order to al-low dierent threads to share the same CPU
Switching can take place in the user space Processes require Interprocess Communication (IPC) (pipes, messagequeues, shared memory) which require kernel intervention
Thread are not automatically protected against each other (no con-currency transparency)
Developing multithreading application requires additional intellectualeort