
Sleeping barber problem - Sami_Lehtinen
https://en.wikipedia.org/wiki/Sleeping_barber_problem
======
degenerate
This is a poor analogy because most barber shops have line-of-sight between
the barbers and waiting room. The "both asleep" issue will never arise in the
real world, and thus, the analogy doesn't help explain the problem.

~~~
mikeash
I'd say it's more of a colorful description than an analogy. Consider the
classic dining philosophers problem for a crazier example. Who eats with both
hands, using different forks, and sharing forks with your neighbor? And yet
being able to visualize it like that helps a lot.

~~~
hedora
The dining philosophers have chopsticks in all the formulations I've seen.
Wikipedia disagrees with me, FWIW.

~~~
musage
Is this some kind of contest in missing the point?

~~~
psyc
This whole thread is.

~~~
mikeash
Wasn't this the whole reason DARPA created the internet in the first place?

------
vacri
> _For example, a customer may arrive and observe that the barber is cutting
> hair, so he goes to the waiting room. While he is on his way, the barber
> finishes the haircut he is doing and goes to check the waiting room. Since
> there is no one there (the customer not having arrived yet), he goes back to
> his chair and sleeps. The barber is now waiting for a customer and the
> customer is waiting for the barber._

This is the critical part of the analogy, and is why it breaks down. It's such
an artificial contrivance to suggest that both the barber and the customer
moving to the waiting room won't notice each other - yes, you can come up with
theoretical ways to do it, but that's requiring contortions in order to
explain what is supposed to be the main point of the analogy.

(it's already a stretch that the barber can't see the waiting clients, as per
degenerate's comment above)

~~~
damagednoob
Totally agree. My initial reaction to this problem was that it could be solved
with a thread-safe queue (usually already implemented in the chosen language).

~~~
connorcpu
Well there would have been no such thing already implemented in a standard
library back in 1965 ;) And it's still a useful exercise for exactly why you
need a thread-safe blocking queue, and probably shouldn't just roll your own
if you don't know what you're doing.

~~~
thaumasiotes
> And it's still a useful exercise for exactly why you need a thread-safe
> blocking queue

Is it? A thread-safe blocking queue sounds like one of those take-a-number
systems you find in some shops. But it would be very common to instead rely on
the standard waiting-customer algorithm, in which, after waiting for some
period of time, the customer gets frustrated and rings the bell at the
counter. Take-a-number systems are vanishingly rare by comparison. Why do you
need the queue?

~~~
imtringued
Nobody has to take a number for a queue to form. Imagine people camping in
front of apple stores for the new iPhone. Nobody is taking numbers yet the
first to arrive also is the first customer that gets an iPhone.

I don't know why I picked such a complicated example.

Did you ever go to the grocery store and had to wait for the people in front
of you? That's also queue and yet nobody is taking numbers.

~~~
ryanwaggoner
I may just be misunderstanding, but if you were to represent a queue of people
waiting in line as a data structure, wouldn't they each have a number, like
their index in an array, etc? How is that different than a take-a-number
system?

Queues are inherently ordered, right? The take-a-number system is still a
queue, it just replaces physical ordering with a paper that shows your place
in line.

