проблема спящего брадобрея

[109]

а вот это, наоборот, явно можно сделать проще, даже когда брадобреев много.

// вначале семафор закрыт
newCustomer = new AutoResetEvent(false); 

// customer reception thread[s]
lock (queue) {
  if (queue.Size == maxSize)
    throw "нет мест";
  queue.Enqueue(сustomer);
  newCustomer.Set(); // open semaphore
}

// each barber's thread
while (true) {
  newCustomer.WaitOne(); // let one barber through and close
  lock (queue) {
    if (queue.IsEmpty) 
      continue;
    customer = queue.Dequeue();
  }
  Shave(customer);
}

собственно, этот же код решает и проблему продюсеров-консъюмеров, вместо того, что там написано (на буфер памяти нет, а спящие треды копить память есть, да?)

Comments

[faceted-jacinth.livejournal.com]

Эм, он volatile для того, чтобы компилятор не соптимизил доступ к нему.

В принципе может быть это и не нужно в данном конкретном случае -- lock сам по себе вроде бы является read-write barrier (но вот насчёт read не уверен, кстати!), однако над такими вещами лучше не задумываться излишне, по-моему.

Не, это barberAwakeningPending имелось в виду!

[109.livejournal.com]

я знаю, зачем нужен volatile, я не понимаю, куда его тут совать. ну обнаружили мы, что нету барберов pending, дальше что? спинлочить? не думаю, что ты это имел в виду. код можешь написать?

и да, lock - это всегда both read and write barrier, (иначе бы не работало ничего).