cs5012009-CHAPTER 3 Processes PROBLEMS

[Hongfei Yan]

1. Q: In this problem you are to compare reading a file using a single-threaded file server and a multithreaded server. It takes 15 msec to get a request for work, dispatch it, and do the rest of the necessary processing, assuming that the data needed are in a cache in main memory. If a disk operation is needed, as is the case one-third of the time, an additional 75 msec is required, during which time the thread sleeps. How many requests/sec can the server handle if it is single threaded? If it is multithreaded?

2. Q: Would it make sense to limit the number of threads in a server process?

3. Q: In the text, we described a multithreaded file server, showing why it is better than a single-threaded server and a finite-state machine server. Are there any circumstances in which a single-threaded server might be better? Give an example.

4. Q: Statically associating only a single thread with a lightweight process is not such a good idea. Why not?

5. Q: Having only a single lightweight process per process is also not such a good idea. Why not?

7. Q: X designates a user’s terminal as hosting the server, while the application is referred to as the client. Does this make sense?

8. Q: The X protocol suffers from scalability problems. How can these problems  be tackled?

10. Q: Constructing a concurrent server by spawning a process has some advantages and disadvantages compared to multithreaded servers. Mention a few.

13. Q: Is a server that maintains a TCP/IP connection to a client stateful or stateless?

14. Q: Imagine a Web server that maintains a table in which client IP addresses are mapped to the most recently accessed Web pages. When a client connects to the server, the server looks up the client in its table, and if found, returns the registered page. Is this server stateful or stateless?

[刘国鹏]

作业提交要用英语吗？

2009/3/8 Hongfei Yan <yhf...@gmail.com>

[Hongfei Yan]

英语，中文都可以。其他语言我看不懂。

[wzhang]

书上 chapter 3 讲 superserver 时以 inetd 为例(89 页) , 有什么具体例子么? linux
下面什么网络服务是 inetd fork 出来的呢?
假如 request 一个接一个的来效率会不会不高呢?

On Mar 8, 8:26 pm, Hongfei Yan <yhf1...@gmail.com> wrote:
> 英语，中文都可以。其他语言我看不懂。
>

> On Sun, Mar 8, 2009 at 8:23 PM, 刘国鹏 <jasonliu...@gmail.com> wrote:
> > 作业提交要用英语吗？
>

> > 2009/3/8 Hongfei Yan <yhf1...@gmail.com>

[Hongfei Yan]

可以看看这个说明
http://linux.die.net/man/8/xinetd

/etc/services里面列的都归它管。

效率问题,具体的协议都有不同的策略，比如http的配置就很多.
具体的量化指标我不清楚。

[Hongfei Yan]

1. Q: In this problem you are to compare reading a file using a single-threaded file server and a multithreaded server. It takes 15 msec to get a request for work, dispatch it, and do the rest of the necessary processing, assuming that the data needed are in a cache in main memory. If a disk operation is needed, as is the case one-third of the time, an additional 75 msec is required, during which time the thread sleeps. How many requests/sec can the server handle if it is single threaded? If it is multithreaded?

A: In the single-threaded case, the cache hits take 15 msec and cache misses take 90 msec. The weighted average is 2/3 × 15 + 1/3 × 90. Thus the mean request takes 40 msec and the server can do 25 per second. For a multithreaded server, all the waiting for the disk is overlapped, so every request takes 15 msec, and the server can handle 66 2/3 requests per second.

2. Q: Would it make sense to limit the number of threads in a server process?

A: Yes, for two reasons. First, threads require memory for setting up their own private stack. Consequently, having many threads may consume too much memory for the server to work properly. Another, more serious reason, is that, to an operating system, independent threads tend to operate in a chaotic manner. In a virtual memory system it may be difficult to build a relatively stable working set, resulting in many page faults and thus I/O. Having many threads may thus lead to a performance degradation resulting from page thrashing. Even in those cases where everything fits into memory, we may easily see that memory is accessed following a chaotic pattern rendering caches useless. Again, performance may degrade in comparison to the single-threaded case.

3. Q: In the text, we described a multithreaded file server, showing why it is better than a single-threaded server and a finite-state machine server. Are there any circumstances in which a single-threaded server might be better? Give an example.

A: Yes. If the server is entirely CPU bound, there is no need to have multiple threads. It may just add unnecessary complexity. As an example, consider a telephone directory assistance number for an area with 1 million people. If each (name, telephone number) record is, say, 64 characters, the entire database takes 64 megabytes, and can easily be kept in the server’s memory to provide fast lookup.

4. Q: Statically associating only a single thread with a lightweight process is not such a good idea. Why not?

A: Such an association effectively reduces to having only kernel-level threads, implying that much of the performance gain of having threads in the first place, is lost.

5. Q: Having only a single lightweight process per process is also not such a good idea. Why not?

A: In this scheme, we effectively have only user-level threads, meaning that any blocking system call will block the entire process.

7. Q: X designates a user’s terminal as hosting the server, while the application is referred to as the client. Does this make sense?

A: Yes, although it may seem a bit confusing. The whole idea is that the server controls the hardware and the application can send requests to manipulate that hardware. From this perspective the X Window server should indeed reside on the user’s machine, having the application acting as its client.

8. Q: The X protocol suffers from scalability problems. How can these problems  be tackled?

A: There are essentially two scalability problems. First, numerical scalability is problematic in the sense that too much bandwidth is needed. By using compression techniques, bandwidth can be considerably reduced. Second, there is a geographical scalability problem as an application and the display generally need to synchronize too much. By using cachinng techniques by which effectively state of the display is maintained at the application side, much synchronization traffic can be avoided as the application can inspect the local cache to
fins out what the state of the display is.

10. Q: Constructing a concurrent server by spawning a process has some advantages and disadvantages compared to multithreaded servers. Mention a few.

A: An important advantage is that separate processes are protected against each other, which may prove to be necessary as in the case of a superserver handling completely independent services. On the other hand, process spawning is a relatively costly operation that can be saved when using multithreaded servers. Also, if processes do need to communicate, then using threads is much cheaper as in many cases we can avoid having the kernel implement the communication.

13. Q: Is a server that maintains a TCP/IP connection to a client stateful or stateless?

A: Assuming the server maintains no other information on that client, one could justifiably argue that the server is stateless. The issue is that not the server, but the transport layer at the server maintains state on the client. What the local operating systems keep track of is, in principle, of no concern to the server.

14. Q: Imagine a Web server that maintains a table in which client IP addresses are mapped to the most recently accessed Web pages. When a client connects to the server, the server looks up the client in its table, and if found, returns the registered page. Is this server stateful or stateless?

A: It can be strongly argued that this is a stateless server. The important issue with stateless designs is not if any information is maintained by the server on its clients, but instead whether that information is needed for correctness. In this example, if the table is lost for what ever reason, the client and server can still properly interact as if nothing happened. In a stateful design, such an interaction would be possible only after the server had recovered from a possible fault.