<<
>>

Проблема читателей и писателей

Проблема обедающих философов полезна для моделирования процессов, соревнующихся за монопольный доступ к ограниченному количеству ресурсов, например к устройствам ввода-вывода. Другой известной проблемой является проблема

читателей и писателей, моделирующая доступ к базе данных [27].

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

Листинг 2.11, Решение проблемы читателей и писателей

typedef int semaphore; /* Воспользуйтесь своим воображением */

semaphore mutex =1; /* Контроль доступа к гс */

semaphore db = 1; /* Контроль доступа к базе данных */

int гс = 0; /* Количество процессов, читающих или */

/* желающих читать */

void reader(void)

{

while (TRUE) { down(&mutex); rc = rc+1;

if (rc == 1) down(&db);

up(&mutex); read_data_base(); down(&mutex); rc = rc-1;

if (rc == 0) up(&db);

up(&mutex); use_data_read();

}

}

void writer(void)

{

while (TRUE) {

think_up_data(); down(&db); write_data_base(); up(&db);

}

}

Первый читающий процесс выполняет операцию down для семафора db, чтобы получить доступ к базе. Последующие читатели просто увеличивают значение счетчика гс.

По мере уменьшения числа читающих из базы значение счетчика уменьшается, и последний читающий процесс выполняет для семафора db операцию up, позволяя блокированному пишущему процессу получить доступ к базе.

В этом решении один момент требует комментариев. Представьте, что в то время как один читатель уже пользуется базой, другой читатель запрашивает к ней доступ. Доступ разрешается, поскольку читающие процессы друг другу не мешают. Доступ разрешается и третьему, и последующим читателям.

Затем доступ запрашивает пишущий процесс. Запрос отклоняется, поскольку пишущим процессам необходим монопольный доступ, и пишущий процесс приостанавливается. Пока в базе есть хотя бы один активный читающий процесс, доступ остальным читателям разрешается, а они все приходят и приходят. Если предположить, что новый читающий процесс запрашивает доступ каждые 2 с, а для работы с базой ему надо 5 с, то пишущий процесс никогда в базу не попадет.

Чтобы избежать такой ситуации, нужно немного изменить программу: если пишущий процесс ждет доступа к базе, новый читающий процесс доступа не получает, а становится в очередь за пишущим процессом. Теперь пишущему процессу нужно подождать, пока базу покинут уже находящиеся в ней читающие процессы, но не нужно пропускать вперед читающие процессы, пришедшие к базе после него. Недостаток этого решения заключается в снижении производительности, вызванном ослаблением конкуренции. В [27] представлено решение, в котором пишущим процессам предоставляется более высокий приоритет.

1.4.

<< | >>
Источник: Э. ТАНЕНБАУМ, А. ВУДХАЛЛ. ОПЕРАЦИОННЫЕ СИСТЕМЫ Разработка и реализация 3-е издание. 2007

Еще по теме Проблема читателей и писателей:

  1. От писателя
  2. От писателя (снова!)
  3. Ф.М. Достоевский. «Дневник писателя». 1876, январь
  4. Ф.М. Достоевский. «Дневник писателя». 1876, март
  5. Ф.М. Достоевский. «Дневник писателя». 1877, декабрь
  6. Писатель или сборщик на конвейере?
  7. СОВЕТ НАЧИНАЮЩИМ ПИСАТЕЛЯМ (Шутка)
  8. Предисловие писателя
  9. Из жизни писателей
  10. Глава седьмая Заключение писателя
  11. Переводчики (см. Журналисты) Писатели, поэты
  12. К ЧИТАТЕЛЮ
  13. Ваши читатели
  14. ШИШКА См. статью ОТЕК, ШИШКОВИДНАЯ ЖЕЛЕЗА (ПРОБЛЕМЫ) См. ЭПИФИЗ (ПРОБЛЕМЫ).
  15. К ЧИТАТЕЛЮ
  16. Что любит читатель?
  17. Уважаемый читатель!
  18. Чего не знает читатель?
  19. СЛОВО К ЧИТАТЕЛЮ
  20. «Проблема» в том виде, в каком мы ее себе представляем, редко оказывается настоящей проблемой