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

[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]

А!

Меня вот что запутало: я же правильно понимаю, что в очереди next никогда не должно быть больше одного кастомера, то есть её можно смело превратить в `Customer next;` и вместо `if (next.count > 0)` писать `if (next != null)`, ну а вместо `next.Dequeue` -- `customer = next; next = null`?

Тогда да, кажется тоже работает.

[faceted-jacinth.livejournal.com]

или даже вообще, volatile bool barberPending. Чтобы как бы совсем понятно было.

[109.livejournal.com]

а это будет уже совсем непонятно. pending-то кастомер, а не барбер.

и куда его совать-то, этот volatile? вместо локов не получится, локи всё равно нужны. а тогда лишний point of synchronization. но всё равно не понимаю, куда.

[faceted-jacinth.livejournal.com]

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

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

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

[109.livejournal.com]

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

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

[109.livejournal.com]

можно и так, но с двумя очередями очевиднее, что происходит (в явном виде употребляются слова enqueue и dequeue), и more generic - мало ли, в следующий раз по два кастомера брать надо будет.