Уильям Стивенс - UNIX - разработка сетевых приложений

43 while (nlefttoread > 0) {

44 while (nconn 0) {

45 /* находим файл для считывания */

46 for (i = 0; i

47 if (file[i].f_flags == 0)

48 break;

49 if (i == nfiles)

50 err_quit("nlefttoconn = %d but nothing found", nlefttoconn);

51 file[i].f_flags = F_CONNECTING;

52 Pthread_create(&tid, NULL, &do_get_read, &file[i]);

53 file[i].f_tid = tid;

54 nconn++;

55 nlefttoconn--;

56 }

57 /* Ждем завершения выполнения одного из потоков */

58 Pthread_mutex_lock(&ndone_mutex);

59 while (ndone == 0)

60 Pthread_cond_wait(&ndone_cond, &ndone_mutex);

61 for (i = 0; i

62 if (file[i].f_flags & F_DONE) {

63 Pthread_join(file[i].f_tid, (void**)&fptr);

64 if (&file[i] != fptr)

65 err_quit("file[i] != fptr");

66 fptr->f_flags = F_JOINED; /* clears F_DONE */

67 ndone--;

68 nconn--;

69 nlefttoread--;

70 printf("thread %d for %s done\n", fptr->f_tid, fptr->f_name);

71 }

72 }

73 Pthread_mutex_unlock(&ndone_mutex);

74 }

75 exit(0);

76 }

44-56 Эта часть кода не изменилась.

57-60 Мы ждем завершения выполнения потоков, отслеживая, когда значение ndoneстанет равно нулю. Как сказано в разделе 26.8, эта проверка должна быть проведена перед тем, как взаимное исключение будет блокировано, а переход потока в состояние ожидания осуществляется функцией pthread_cond_wait.

61-73 Когда выполнение потока завершилось, мы перебираем все структуры file, отыскивая соответствующий поток, вызываем pthread_join, а затем устанавливаем новый флаг F_JOINED.

В табл. 16.1 показано, сколько времени требует выполнение этой версии веб-клиента, а также версии, использующей неблокируемую функцию connect.

Создание нового потока обычно требует меньше времени, чем порождение нового процесса с помощью функции fork. Одно это уже является большим преимуществом использования потоков на активно работающих сетевых серверах. Многопоточное программирование, однако, представляет собой отдельную технологию, требующую большей аккуратности при использовании.

Все потоки одного процесса совместно используют глобальные переменные и дескрипторы, тем самым эта информация становится доступной всем потокам процесса. Но совместное использование информации вносит проблемы, связанные с синхронизацией доступа к разделяемым переменным, и поэтому нам следует использовать примитивы синхронизации технологии Pthreads — взаимные исключения и условные переменные. Синхронизация доступа к совместно используемым данным — необходимое условие почти для любого приложения, работающего с потоками.

При разработке функций, которые могут быть вызваны таким приложением, нужно учитывать требование безопасности в многопоточной среде. Это требование выполнимо при использовании собственных данных потоков (thread-specific data), пример которых мы показали при рассмотрении функции readlineв этой главе.

К модели потоков мы вернемся в главе 30, где сервер при запуске создает пул потоков. Для обслуживания очередного клиентского запроса используется любой свободный поток.

1. Сравните использование дескриптора в случае, когда в коде сервера применяется функция fork, и в случае, когда используются потоки. Предполагается, что одновременно обслуживается 100 клиентов.

2. Что произойдет в листинге 26.2, если поток при завершении функции str_echoне вызовет функцию closeдля закрытия сокета?

3. В листингах 5.4 и 6.2 мы выводили сообщение Server terminated prematurely(Сервер завершил работу преждевременно), когда мы ждали от сервера прибытия отраженной строки, а вместо этого получали признак конца файла (см. раздел 5.12). Модифицируйте листинг 26.1 таким образом, чтобы в соответствующих случаях также выдавалось аналогичное сообщение.

4. Модифицируйте листинги 26.5 и 26.6 таким образом, чтобы программы можно было компилировать в системах, не поддерживающих потоки.

5. Чтобы увидеть ошибку в функции readline, приведенной в листинге 26.2, запустите эту программу на стороне сервера. Затем измените эхо-клиент TCP из листинга 6.2, корректно работающий в пакетном режиме. Возьмите какой- либо большой текстовый файл в своей системе и трижды запустите клиент в пакетном режиме, чтобы он считывал текст из этого файла и записывал результат во временный файл. Если есть возможность, запустите клиенты на другом узле (не на том, на котором запущен сервер). Если все три клиента выполнят работу правильно (часто они зависают), посмотрите на файлы с результатом и сравните их с исходным файлом.