Can a read() in one thread block all threads in a process?

[Krister Valtonen]

We have developed a multi-threaded server application running on a HP-UX 11.23 ia64 system. The main task of the server is to handle files (move, copy, compress, decompress, etc.) on request from clients. Each client is handled by a separate thread. The application is typically serving around 10 clients at a time.

On a specific site which has an underlying HSM system there is a problem of intermittent freezing of the whole process. The whole process seems to be nothing for up to two-three minutes, and then starts to work normally again. During this time it can not even handle a simple "ping" request from our own developed server monitor.

We have used tools like lsof, tusc, gdb trying to pinpoint the problem. Using pst_status->pst_cmd we have noticed that during a freeze one of the threads in the process is always doing a read(). The read() is likely to be correlated to a first read of a file from the HSM system. When we moved the read() to a separate process, the freezing disappeared.

Is it possible that a read() in one thread of the process can freeze all threads of the process? I thought that the whole point with kernel threads was to aviod these kind of problems.

[Dennis Handly]

>Is it possible that a read() in one thread of the process can freeze all threads of the process?

Only if the other threads are doing I/O to the same file.
Are you doing any locking between threads? Using stdio on the same file between threads?

[Krister Valtonen]

>>Is it possible that a read() in one thread of the process can freeze all threads of the process?

>Only if the other threads are doing I/O to the same file.
>Are you doing any locking between threads? Using stdio on the same file between threads?

No, the file that is active in the read() call mentioned is never accessed from other threads at the same time. However, we are doing stdio on the log file from all of the threads. The thought have crossed our mind that this can be the link that is making the process to freeze. However, the thread that is locked in the read() call is currently not reading the log file, but a separate file, always from the HSM system. Could the log file explain the behaviour?

[Dennis Handly]

>Could the log file explain the behaviour?

Possibly. Though since you aren't deadlocked, I'm not sure why the delay.
Is your log file on some NFS system? Would you be writing more than 8 Kb to the log, when it hangs?